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by 
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1.  ABSTRACT 

The  Defensive  Technology  Evaluation  Code  (DETEC)  is  being  developed  to  assess  the  potential  of  a 
realistically  diverse  assortment  of  strategic  defense  and  offense  assets  deployed  on  all  sides  in  possible  global 
conflict.  Principal  applications  of  the  code  will  be  to  study  the  roles  of  the  various  weapon  technology 
concepts  being  explored  for  strategic  defense.  Technology  requirements  and  sensitivities  will  be  studied 
in  the  context  of  complete  wan  built  up  from  many  individual  one-on-one  engagements.  DETEC  will 
also  provide  an  important  vehicle  with  which  to  develop  and  test  various  possible  algorithms  for  battle 
management  and  for  communications  and  control. 

The  DETEC  simulation  features  a  wide  span  of  capabilities.  It  includes  each  important  object  with 
separate  modular  representations  of  each  replica  decoy,  re-entry  vehicle,  missile,  submarine,  satellite,  etc. 
Such  complete  offensive  and  defensive  inventories  are  employed  on  all  sides  of  an  arbitrarily  many-sided 
conflict.  The  one-on-one  engagement  modules  are  statistical  processes  based  upon  accurate  physical  models. 
Damage  to  individual  assets  is  simulated  by  operating  parameters  that  may  be  continuously  varying,  giving 
simulated  performance  from  full  to  zero  capability. 

Countermeasures  are  explicitly  included.  Each  sensor,  weapon,  and  control  and  communications  sys¬ 
tem  is  modeled  by  a  library  of  code  modules  allowing  the  user  to  balance  the  needs  of  his  problem,  the 
fidelity  levels,  and  the  computational  costs.  Stresses  on  the  operating  environment  include  both  natural 
(sun,  moon,  storms)  and  battle-driven  (jamming,  weapon,  nuclear)  effects.  DETEC  is  event  driven,  with 
both  instantaneous  and  time-extended  events  allowed.  Conflicts  between  extended  events  and  instanta¬ 
neous  or  other  extended  events  are  identified  and  explicitly  accommodated.  Separate  files  are  maintained 
for  the  “real”  data,  the  perceived  data  of  each  combatant,  and  that  of  each  combatant's  subsystems. 

The  modular  code  structure  is  developed  for  efficient  execution  on  our  Cray-X  computer.  A  true  restart 
capability  allows  a  simulation  to  be  restarted  with  or  without  modifications,  which  may  include  arbitrary 
interventions.  Convenient  user  interaction  and  powerful  graphics-based  postprocessing  are  important  design 
functions.  Although  we  draw  on  the  experience  of  existing  military  simulations,  DETEC  is  a  new  product 
that  relies  heavily  on  our  experience  with  efficient  supercomputer  codes  for  the  design  of  nuclear  weapons. 

Our  design  procedure  has  utilized  both  the  formal  methods  and  concepts  of  structured  program  design. 
The  substance  of  this  document  describes  the  design  specifications  (data  flow,  data  definitions,  and  control 

flow). 

Ideas  and  suggestions  for  this  document  have  been  incorporated  from  a  large  group  of  people  including 
Laboratory  consultants,  other  employees,  researchers  at  many  military  operations  research  establishments, 
and  their  contractors.  For  this  help  and  encouragement  we  are  grateful. 
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2.  INTRODUCTION 


The  Defensive  Technology  Evaluation  Code  (DETEC)  simulation  is  an  analytical  tool  for  general  ap¬ 
plication  to  systems  studies  within  the  strategic  defense  program.  The  code  is  intended  to  be  capable  of 
simulating  engagements  between  any  arbitrary  strategic  offensive  and  defensive  systems,  given  code  modules 
describing  the  set  of  weapons  effects  of  interest  against  assets  of  interest.  In  order  to  do  this,  DETEC  has 
been  designed  as  a  very  general  simulation  system  with  scenario-dependent  coding  confined  to  modular  code 
subunits  that  may  be  “plugged  into”  the  general  DETEC  framework.  It  is  intended  that  a  large  catalog  of 
the  individual  modules  will  be  acquired,  and  it  is  hoped  that  many  of  them  will  be  contributed  by  members 
of  the  community  outside  the  DETEC  team  and  outside  Los  Alamos  National  Laboratory.  The  capability 
to  simulate  virtually  any  arbitrary  engagement  requires  treatment  of  the  entire  earth  and  its  near  vicinity  (at 
least  out  to  geosynchronous  orbit)  and  the  ability  to  simulate  and/or  keep  track  of  a  large  number  of  assets. 
Estimates  range  from  some  thousands  of  objects  in  a  limited  engagement  to  upwards  of  fifty  thousand  in  a 
full-scale  exchange. 

The  corresponding  code  may  therefore  be  thought  of  as  a  large,  specialized  data  base  code,  with  the  state 
of  the  “world”  being  represented  in  several  million  words  of  computer  memory.  Several  computer  processes 
are  invoked  to  set  up  this  data  base,  others  are  invoked  to  move  it  forward  in  time,  while  still  others  are 
used  to  report  the  progress  to  the  users  both  interactively  and  through  various  postprocess  reports. 

DETEC  simulation  capability  allows  a  user  to  investigate  the  efficacy  of  weapons,  sensor,  battle  man¬ 
agement,  and  communications  systems,  as  well  as  the  effect  of  policy  and  strategy.  The  sensitivity  of  a 
system’s  effectiveness  to  technology  assumptions  and  design  and  deployment  parameters  can  be  studied  un¬ 
der  full  campaign  conditions.  Both  natural  (e.g.,  weather,  electromagnetic  environment)  and  engagement- 
induced  stresses  (e.g.,  nuclear  effects,  electronic  warfare)  are  simulated.  Countermeasures  can  be  explicitly 
simulated.  The  modular  nature  of  individual  assets  and  physics  simulators  allows  them  to  be  written  to 
the  fidelity  required  for  a  particular  application  without  modifying  any  other  part  of  the  DETEC  system. 
Medium  to  high-fidelity  battle  management  simulation  requires  the  concept  of  “perceived  worlds"  as  opposed 
to  the  “real  world."  This  refers  to  the  inevitable  incompleteness  and  inaccuracy  of  the  information  available 
to  a  battle  manager-his  “perceived  world"  as  derived  from  his  sensor.  In  contrast,  the  code  will  maintain  a 
data  file  containing  an  accurate  (by  definition)  description  of  each  object  included  in  the  simulation.  This 
file  is  termed  the  REAL-WORLD. 

Each  object  description  is  a  data  structure  that  has  been  named  a  STATE-VECTOR.  DETEC 
STATE-VECTORS  are  hybrid  structures-they  contain  a  complete  parameterized  description  of  an  object’s 
state  and  kinematics  (like  a  quantum  mechanical  state  vector),  and  they  also  contain  an  evaluation,  for  a 
particular  instant  in  time,  of  a  subset  of  the  possible  descriptive  variables.  This  subset  will  always  include 
position  and  may  include  other  quantities,  depending  on  the  class  of  object  described. 

The  volume  of  space  from  the  surface  of  the  earth  out  to  some  user-defined  limiting  radius  may  in 
DETEC  be  divided  into  some  number  of  angle  and  radius  limited  sectors.  This,  like  the  evaluation  of  the 
position,  is  a  calculational  efficiency  feature.  The  sector  in  which  an  object  is  located  will  be  stored  in  the 
object’s  state  vector  and  changed  as  updated  positions  require.  The  sector  locations  are  used  to  limit  the 
number  of  state  vectors  that  must  be  considered  for  position-dependent  calculations  (such  as  what  a  sensor 
can  see  or  with  what  a  weapon  effect  will  interact).  The  positions  data  in  the  state  vector  can  be  used  as  is 
for  relatively  slowly  moving  objects,  or  it  can  be  updated  to  the  exact  current  simulation  time  if  the  physics 
and  fidelity  require  it. 

Geographical  and  environmental  data  will  also  be  referenced  by  sector.  Environmental  influences  at  a 
particular  point  will  be  treated  as  caused  by  two  additional  components;  a  slowly  varying  component  that  is 
calculated  at  routine  update  intervals  and  parameterized  by  sector,  and  a  rapidly  varying  component  that 
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is  calculated  from  individual  “source*  state  vectors  as  needed. 

The  processes  simulated  by  DETEC  may  be  considered  to  fall  into  two  classes:  those  whose  time 
evolution  is  (relatively)  easily  parameterized  and  predicted  and  those  whose  time  evolution  is  potentially 
complex.  Examples  of  the  first  class  of  processes  are  both  powered  and  free  motion,  the  development  and 
evolution  of  a  localized  weather  system,  and  the  expansion  of  a  nuclear  fireball  Examples  of  the  second  class 
are  the  functioning  of  a  sensor,  weapon,  battle  manager  or  communications  installation,  or  the  interaction 
of  a  weapons  effect  with  an  asset.  Processes  of  the  first  type  are  not  explicitly  simulated  by  DETEC; 
their  behavior  is  built  into  pertinent  subroutines  by  algorithms  using  state  vector  parameters  to  provide 
specific  evaluations  as  needed.  Changes  in  these  parameters  (analogous)  to  a  transition  between  quantum 
mechanical  states)  are  explicitly  simulated.  Processes  of  the  second  type  compose  the  bulk  of  DETEC’s 
simulation  task.  These  calculations  are  performed  by  individual  asset  and  physics  simulation  modules 
chosen  from  the  DETEC  module  catalog.  These  simulation  calculations  are  triggered  by  a  precalculated 
instruction  termed  an  EVENT, 

An  EVENT  is  a  data  structure  containing  a  specification  of  what  asset  or  physical  process  is  to  be 
simulated  and  when  it  is  to  occur.  EVENTs  can  be  created  at  code  initialization  or  directly  by  the  user, 
but,  as  a  rule,  they  are  constructed  by  asset  or  physics  simulation  modules  themselves, 

DETEC  calculates  what  subsequent  occurrences  are  required  (as  in  the  case  of  battle  managers)  or 
caused  by  a  particular  simulated  action,  and  EVENTs  to  trigger  the  simulations  of  these  processes  are 
constructed,  EVENTs  may  be  treated  as  either  instantaneous  (being  of  negligible  duration)  or  extended. 
Instantaneous  events  are  marked  by  a  single  EVENT,  Extended  events  require  an  EVENT  to  mark  the 
beginning  of  the  process  and  a  second  EVENT  to  mark  its  end.  It  is  possible  for  an  extended  event  to  occur 
over  a  period  during  which  the  state  of  an  asset  involved  in  the  process  is  being  changed  by  another  event. 
Such  situations  have  been  termed  conflicts  and  are  identified  and  resolved  by  one  of  two  methods.  If  the 
structure  of  the  conflict  allows  and  the  specific  code  modules  are  able,  a  conflict  may  be  resolved  by  saving 
copies  of  the  changing  state  vector.  This  information  would  then  be  used  to  calculate,  at  the  simulation 
time  corresponding  to  the  end  of  the  event,  the  process  simulation  for  the  entire  time  period  of  the  event. 
Otherwise,  the  conflicting  events  are  divided  into  a  number  of  time  steps  suitable  for  the  characteristic  times 
of  the  processes  involved,  and  the  state  vectors  are  used  as  constants  during  each  time  step. 

The  time-ordered  series  of  EVENTs  is  termed  the  EVENT.Q*  and  the  simulation  proceeds  from  event 
to  event  in  the  queue,  with  no  calculational  investment  in  the  parameterized  “easy"  processes  between 
EVENTs. 

The  EVENT.Q  also  contains  EVENTs  that  are,  using  the  above  definition,  “nonevents.”  These  are 
markers  that  trigger  periodic  displays,  logging  functions,  and  updates  of  the  evaluated  portion  of  the  state 
vector  and  environmental  data.  Their  inclusion  as  “none  vents”  or  “pseudo-events”  allows  a  simple  control 
structure  for  the  main  execution  loop. 

The  general  DETEC  code  structure  reflects  a  division  by  function  into  five  main  units.  The  user  in¬ 
terface  and  code  initialization  are  performed  by  the  code  MANAGER,  The  user  interface  accommodate:; 
interactive  graphical  setup,  checkout,  and  monitoring  functions.  The  setup  of  a  simulation  requires  specifi¬ 
cation  of  the  order-of-battle  (numbers,  characteristics,  and  employment  of  assets);  battle  manager  “policy” 
instructions  (parameter  sets  tailored  to  the  design  of  the  particular  module  selected);  physics  and  asset  mod¬ 
ule  selection  consistent  with  the  preceding  natural  environment  parameters;  and  any  specific  events  desired 
by  the  user.  This  may  be  accomplished  by  commands  entered  directly  from  the  terminal  or  by  assigning  a 
file  containing  a  list  of  commands  (an  INFILE).  Setup  may  be  “from  scratch”  or  based  on  any  other  partial 


INTRODUCTION 


2-2 


2.  INTRODUCTION 


or  complete  DETEC  problem  specification  defined  through  a  restart  file  or  one  or  more  INFILEs. 

A  restart  modification  is  conceptually  identical  to  a  referee-type  intervention,  and,  in  DETEC,  this 
intervention  mechanism  will  allow  user  intervention  in  virtually  all  aspects  of  the  simulation. 

The  code  initialization  functions  performed  by  the  MANAGER  include  construction  of  the  REAL- 

WORLD  and  PERCEIVED  WORLDS  flies,  as  well  as  the  initial  EVENT.Q  and  setup  of  code  and  system 
parameter  tables.  Module  and  data  libraries  will  be  assigned. 

Running  and  monitoring  parameters,  such  as  selection  of  a  graphics  display,  how  frequently  to  update 
the  display,  the  type  and  frequency  of  data  logging,  and  how  often  to  write  restart  dumps  will  be  part  of 
a  simulation  nm  setup.  The  user  also  specifies  the  set  of  optional  variables  to  be  written,  in  addition  to 
a  large  set  of  standard  variables,  into  postprocessor  files.  These  data  provide  periodic  “snap-shots”  of  the 
simulation.  From  these  files,  the  postprocessor  can  provide  the  following:  graphical  or  tabular  data  for 
specific  simulation  times,  time  histories  of  simulated  quantities,  and  comparisons  of  these  data  for  different 
times,  variables,  or  different  DETEC  simulation  runs.  For  convenience,  the  postprocessor  has  the  same 
user  interfaces  as  the  main  DETEC  code,  with  all  common  function  commands  being  identical. 

Control  functions  for  the  DETEC  simulation  execution  are  centralized  in  the  code,  EXECUTIVE.  The 
EXECUTIVE  sequentially  processes  the  events  in  the  EVENT-Q,  identifying  and  calling  the  appropriate 
code  unit  to  execute  that  particular  event.  For  each  extended  or  instantaneous  event,  the  executive  identifies 
conflict  situations  and  either  provides  for  storage  of  changing  state  vectors  or  constructs  an  event  to  trigger 
the  subdivision  of  one  or  more  extended  events  into  shorter  events  in  order  to  resolve  the  conflict  as  discussed 
above. 

The  periodic  evaluation  of  some  parameterized  state  vector  variables  is  performed  in  a  code  unit  nick¬ 
named  MOTHER  NATURE.  This  code  unit  is  itself  functionally  divided,  with  modules  for  each  class  of 
state  vector  and  environmental  phenomena.  Modules  with  varying  degrees  of  sophistication  may  be  selected 
at  run  time  to  allow  choices  of  fidelity  and  concomittant  computing  costs.  The  time  periods  between  regular 
updates  are  chosen  to  reflect  the  characteristics  time  scale  for  the  processes  involved. 

Each  time  MOTHER -NATURE  is  called,  it  calculates  an  update  interval  and  puts  an  appropriate 
EVENT  in  the  EVENT-Q.  Each  MOTHER-NATURE  caU  will  be  for  a  set  of  classes  of  STATE-VECTORS 
and/or  environmental  quantities,  and  every  member  of  each  of  these  classes  is  updated  in  a  single  call.  In¬ 
dividual  MOTHER  JMATURE  subroutines  may  be  called  by  other  code  modules  to  allow  accurate  evaluation 
of  critical  or  sensitive  parameters,  but  the  updated  information  is  used  only  locally  and  is  not  stored  in  the 
REAL-WORLD. 

The  salient  features  of  the  engagement  simulation  are  accomplished  in  the  portion  of  the  code  termed 
ENGAGEMENT.  ENGAGEMENT  contains  the  asset  simulation  modules  and  communications  and  inter- 
action  physics  subroutines.  It  is  itself  divided  by  function  into  BATTLE -MANAGERS,  SENSORS,  COM¬ 
MUNICATIONS,  WEAPONS,  AND  EVENT-PHYSICS. 

These  names  are  applicable  in  the  very  general  sense:  any  analytical  function,  be  it  human  or  a  mi¬ 
croprocessor,  is  termed  a  battle  manager,  and  any  means  of  acquiring  information  is  a  sensor.  Because 
of  this  structure,  co- located  but  distinguishable  functions  of  a  particular  installation  (such  as  the  sensor, 
communications,  and  analysis  functions  of  an  intelligent  surveillance  platform)  wiU  be  simulated  separately. 
AU  communications  are  treated  as  discrete  messages  contained  in  data  structures  named  INFO-PACKETS. 
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It  is  in  the  ENGAGEMENT  that  the  modularity  of  DETEC  is  most  important,  because  the  simulation 
of  a  variety  of  systems  will  require  a  wide  range  of  asset  simulation  capabilities.  Studies  with  a  different 
emphasis  will,  in  general,  have  different  fidelity  requirements,  all  of  which  are  accomplished  by  selecting 
modules  suitable  to  the  application.  The  array  of  modules  is  specified  by  the  user  as  part  of  the  setup 
processes,  and  DETEC  extracts  the  required  modules  from  the  library  and  links  them  as  part  of  the  run 
initialization. 

The  data  LOGGER  is  the  fifth  main  unit  of  DETEC.  It  may  be  called  directly  by  the  user  from  the 
MANAGER  or,  periodically,  by  the  EXECUTIVE  during  execution.  In  addition  to  writing  a  variety  of 
code  data  to  one  or  several  output  flies,  the  LOGGER  creates  user  displays,  restart  files,  and  postprocessor 
files. 
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In  order  to  develop  high-quality  and  maintainable  software,  the  DETEC  project  is  utilising  structured 
design  and  implementation  techniques  organized  into  a  project  development  cycle.  This  approach  is  moti¬ 
vated  by  the  following  numbers  for  typical  software  projects:  In  a  normal  development  project  15%  of  the 
time  is  spent  on  programming  while  50%  is  spent  on  debugging.  The  average  electronic  data  processing 
(EDP)  organization  spends  50%  of  its  software  budget  on  maintenance.  About  80%  of  software  mainte¬ 
nance  cost  is  repairing  design  errors.  Using  the  structured  techniques,  coupled  with  careful  reviews  reduces 
the  number  of  design  errors  and  produces  high-quality  and  maintainable  programs.  The  cost  over  the  life¬ 
time  of  the  software  is  expected  to  be  significantly  less  than  that  of  programs  developed  using  conventional 
techniques. 

The  development  cycle  for  the  DETEC  project  is  proceeding  as  described  below: 

1.  Define  requirements:  This  step  involved  talking  to  potential  users  and  visiting  other  sites  that  might 
have  a  competing  product.  No  formal  documentation  was  developed  as  a  result  of  this  step.  It  did 
provide  essential  input  to  the  steps  below. 

2.  Do  a  high-level  logical  design:  This  step  resulted  in  a  design  that  described  the  logical  operation  and 
functions  of  the  simulation.  It  described  how  the  product  would  work  independently  of  the  target  op¬ 
erating  system  and  implementation  languages.  The  output  from  this  design  step  is  data-flow  diagrams 
showing  the  processes  required  for  the  system  and  the  data  flow  between  the  processes.  The  processes 
were  defined  using  verbal  descriptions  and  a  Problem  Definition  Language  (PDL).  The  standard  form 
of  the  PDL  is  defined  in  the  internal  project  guidelines  document,  Ref.  1.  The  processes  and  data 
are  defined  to  a  level  of  detail  required  for  an  adequate  description.  The  method  used  to  develop  this 
specification  is  called  Structured  Analysis  and  is  given  in  Ref.  2.  The  specification  you  are  reading 
is  the  output  from  this  step.  An  important  part  of  this  step  is  several  reviews  and  walkthroughs  to 
determine  if  the  proposed  product  meets  requirements  and  will  perform  as  expected. 

3.  Convert  to  a  high-level  physical  design:  Thu  step  converts  the  logical  design  into  a  structured  design  that 
incorporates  the  details  of  the  target  operating  system  and  implementation  language.  Using  structured 
design  techniques  allows  the  design  to  be  completed  and  the  result  evaluated.  The  documentation  from 
this  step  is  a  set  of  structure  charts  that  show  the  hierarchical  structure  of  the  program  modules  and  their 
data  flow.  The  data  definitions  and  process  definitions  from  the  logical  design  are  refined  as  necessary. 
Interna]  project  reviews  of  this  step  are  conducted  as  sections  of  the  program  design  are  completed. 
The  method  used  to  develop  this  specification  is  given  in  Ref.  3  and  4. 

Step  4,  5,  and  6  are  done  as  functional  sections  of  the  program  are  designed  and  implemented.  For 
example,  the  detailed  design  for  a  battle-  manager  simulator  would  be  done  followed  by  coding,  checkout, 
and  putting  the  new  function  on  the  system.  This  is  then  repeated  for  other  functions. 

4.  Prepare  the  detailed  design:  This  step  completes  the  detailed  design  of  the  internals  of  subroutines 
and  other  modules.  This  is  the  precise  solution  to  the  problem.  The  level  of  detail  is  such  that  these 
specifications  can  be  given  to  a  good  software  technician  for  coding,  integration  into  the  system  and  top 
down  checkout.  The  detailed  specifications  are  done  using  the  PDL  notation  developed  by  the  project. 
Ref.  1.  Reviews  are  conducted  on  detailed  specifications  as  sections  of  the  specifcations  are  completed. 

5.  Code  and  check  out  the  detailed  design:  This  step  involves  converting  the  PDL  to  Cray  FORTRAN, 
having  a  clean  compile  reviewed,  installing  the  code  into  the  test  system,  and  checking  it  out.  This  is 
then  followed  by  another  review  if  major  changes  were  made.  The  coding  is  done  using  the  standards 
for  Cray  FORTRAN  given  by  the  project  guidelines  document,  ReL  1. 

6.  Place  the  program  under  change  control:  The  program  is  placed  under  change  control  using  the  HIS- 
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TORIAN  system,  Ref,  5*  It  becomes  available  to  the  users  when  the  next  new  system  is  brought  up* 
The  method  for  implementation  change  control  has  not  yet  been  specified* 

This  specification  was  developed  using  the  design  technique  called  Structured  Analysis,  Ret  2.  The 
standard  notation  that  we  adopted  is  given  in  Appendix  A*  There  are  several  parts  to  the  specification. 
The  most  obvious  is  a  data-flow  diagram*  Here  the  processes  (modules)  composing  the  system  are  shown 
along  with  the  data  that  are  being  transferred  between  modules  and  to/from  files  and  data  sources /sinks, 
e*gM  users*  This  is  a  mode)  of  the  system  from  the  perspective  of  the  data  flowing  through  the  system  and 
the  transformation  of  the  data  by  the  identified  processes*  The  data  are  defined  in  more  detail  in  a  data 
dictionary  using  a  standard  data  definition*  When  defining  a  system,  it  is  useful  to  start  at  a  high  level  with 
just  a  few  processes  and  data  flow  and  then  further  refine  the  processes  into  additional  processes  with  their 
data  flows  and  files*  This  design  refinement  continues  until,  at  some  point,  the  function  of  some  particular 
process  is  well  understood  and  its  internal  workings  are  specified  in  detail  using  a  verbal  description  and  a 
short  PDL.  The  design  process  is  complete  when  all  the  lowest  level  processes  have  been  defined  by  a  PDL 
and  all  the  data  have  been  defined* 

The  notation  used  is  that  the  well  understood  areas  in  the  pdls  are  defined  using  all  upper  case  letters. 
Less  well  understood  areas  are  defined  using  lower  case. 

The  bulk  of  the  actual  specification  resides  in  sections  5-8  of  this  document* 

5.  LEVEL  0  DATA  FLOW  AND  DESCRIPTIONS:  This  section  contains  the  highest-level  data-flow  dia¬ 
gram  for  the  simulation.  It  is  similar  to  a  system- level  diagram.  It  also  contains  a  verbal  description 
of  the  high-level-processes.  The  data  flows  and  files  used  are  defined  in  Section  8. 

0.  LEVEL  1  DATA  FLOW  AND  DESCRIPTIONS:  This  section  contains  the  first  expansion  of  all  the 
processes  from  level  0*  Some  processes  are  defined  using  a  verbal  description  while  others  can  be 
defined  using  the  PDL.  The  data  flows  and  files  are  once  again  defined  in  Section  8. 

7.  LEVEL  2  DATA  FLOW  AND  DESCRIPTIONS:  This  section  contains  a  further  expansion  of  some  of 
the  processes  from  level  I  that  require  a  more  precise  description.  All  of  the  processes  are  defined  using 
verbal  descriptions  and  PDLs*  The  data  flows  are  defined  in  Section  8* 

8.  DATA  DEFINITIONS:  This  section  is  a  data  dictionary  that  defines  all  data  flows  and  files  needed  by 
the  level  0,  I,  and  2  data-flow  diagrams  and  process  specifications.  The  data  definitions  are  done  to  a  level 
of  precision  needed  by  the  rest  of  the  specification*  Some  contain  only  a  verbal  description  while  other  are 
defined  down  to  the  data-element  level.  In  a  very  real  sense,  this  is  an  essential  part  of  the  specification 
because  it  provides  a  functional  grouping  for  the  system  data  and  files. 
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4.  SCENARIO  EXAMPLE 


Thorough  code  walkthroughs  are  an  essential  part  of  the  DETEC  code-specification  process.  The  pur¬ 
pose  of  walkthroughs  is  to  verify  that  the  code,  as  specified,  will  perform  as  expected.  Walkthroughs  are 
therefore  required  to  exercise  the  mqor  code  elements  and  functions.  It  must  also  be  assured  that  all  mqor 
types  of  events,  especially  all  types  of  potentially  troublesome  events,  occur  during  the  walkthrough. 

The  DETEC  preliminary  walkthrough  excluded  the  MANAGER  functions.  It  included  most  of  the  EX¬ 
ECUTIVE  functions,  MOTHER  J'lATURE,  and  all  classes  of  engagement  modules  {BATTLE .MANAGERS 
SENSORS,  COMMUNICATIONS,  WEAPONS,  and  EVENT-PHYSICS). 

The  walkthrough  was  accomplished  by  defining  a  set  of  initial  conditions,  which  included  one  or  more 
driving,  or  “trigger"  events  or  conditions  (such  as  launch  boosters),  and  then  following  the  simulation 
step  by  step  through  the  module  PDLs.  For  a  discussion  of  PDL  s  see  Section  3  .  Simple  but  typical 
characteristics  were  defined  for  the  individual  physics  and  asset  simulator  modules.  The  PDLs  were  written 
to  reflect  these  characteristics  and  the  requirement  for  a  variety  of  event  types  (instantaneous,  extended, 
and  conflicted).  MOTHER  .NATURE  was  designed  to  handle  both  discrete  objects  and  grid  quantities. 

The  following  assets  were  chosen  for  a  two-sided,  offensive/defensive  engagement: 

10  ICBMs  with  busses  (4  RVs  per  bus) 

6  sensors  (exoatmospheric) 

1  AWACS  platform  (associated  with  terminal  defense) 

1  terminal  defense  system  (Sprint-like) 

2  space-based  defensive  weapons 

1  particle  beam 
1  laser 

2  “BOSS"  battle  managers 
10  local  battle  managers 

1  on  terminal  defense 
1  on  AWACS 
6  on  sensors 
1  on  laser 
1  on  particle  beam 

The  necessary  MOTHER  .NATURE  functions  for  these  assets  are  the  following: 
booster  burn 

exoatmospheric  ballistic  flight 
endoatmospheric  ballistic  flight  with  weather  effects 
nuclear  effects 
thermal 
blast 

prompt  nuclear  radiation 

charged  particles  in  the  earth’s  magnetic  field 
powered  endoatmospheric  flight  with  weather  effects 
weather. 
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EVENT-PHYSICS  included  the  following: 

User  effects  on 
boosters 

midcourse  vehicles 
RVs 

particle  beam  on 
boosters 

midcourse  vehicles 
RVs 

nuclear  effects 

thermal  on  RVs 
blast  on  AWACS 

prompt  radiation  on  Boss  battle  manager 

firing  of 

boosters 

interceptors 

deployment  of  RVs 

STATE -VECTOR  creation  and  destruction  for  all  weapons. 

Each  BATTLE  .MANAGER  and  SENSOR  bad  associated  communication  functions. 

The  walkthrough  geometry  was  limited  to  a  single  plane  with  all  orbits  circular  and  within  that  plane. 
Correct  physics  was  not  as  important  to  the  walkthrough  as  representative  behavior,  so  circular  orbits  of 
any  altitude  and  orbital  velocity  were  allowed. 

The  walkthrough  was  documented  by  a  summary  of  each  EVENT  and  copies  of  the  contents  of  essentia) 
files  at  the  end  of  the  EVENT.  The  files  documented  were  the  following:  EVENT-Q,  IN-PROGRESS, 
REAL-WORLD,  PERCEIVED -WORLDS,  and  PATH  JUNCTIONS.  The  other  files  shown  in  the  DETEC 
level  0  data-  flow  diagram  are  associated  with  MANAGER  or  LOGGER  functions,  which  were  not  treated 
in  the  walkthrough. 
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Level  0 


DETEC 

Level  0  Data  Flow 
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S.  LEVEL  0  DATA  PLOW  AND  DESCRIPTIONS 


1.0  MANAGER 

The  Manager  provides  the  user  with  a  human-engineered  interface  to  the  simulation.  The  user  can  set 
up  simulation  initial  conditions,  observe  and  change  execution,  and  view  results  after  the  run. 

EXAMPLE:  Simulate  a  two-combatant  war  with  one  side  having  offense  only  and  the  other  having 
offense  and  defense. 

2.0  EXECUTIVE 

The  Executive  provides  overall  control  of  the  simulation  execution,  uses  the  list  of  time-ordered  events 
(EVENT-Q)  to  determine  which  functions  to  run  next,  and  resolves  conflicts  between  simulation  assets. 

EXAMPLE:  Start  a  sensor  module  that  looks  at  space  once  per  second. 

3.0  MOTHER  NATURE 

Mother  Nature  does  the  orderly  evolution  of  currently  existing  real-  world  objects  and  also  updates  the 
real-world  environment. 

EXAMPLE:  Update  the  position  of  all  RVs. 

4.0  ENGAGEMENT 

Engagement  simulates  the  actual  assets,  decisions,  and  interactions  involved  in  the  battle  and  also  does 
the  birth  and  death  of  natural  objects. 

EXAMPLE:  An  ICBM  was  intercepted  by  a  laser  beam;  determine  the  extent  of  the  damage  to  the 
ICBM. 

5.0  LOGGER 

The  Logger  outputs  log  messages,  restart  dumps,  and  postprocessing  data  and  updates  real-time  displays. 
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Manager 
Executive 
Mother  Nature 
Engagement 
Logger 
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1.  MANAGER 

1.1  GENERATE  AND  MODIFY  SCENARIO 

Based  on  user  instructions,  this  process  creates  a  new  or  modifies  an  existing  scenario  file.  This  includes 
defining  the  simulation  configuration  environment,  battle-manager  instructions,  and  any  planned  interven- 
tions. 

EXAMPLE:  Define  the  scenario  for  war  between  countries  A  and  B.  Side  A  has  two  ICBMs  and  side 
B  has  five  anti-ICBM  weapons.  The  side-B  battle  manager  uses  kill-at-first-chance  tactic. 

1.2  SETUP  AND  INTERVENTIONS 

This  process  allows  the  user  to  complete  the  simulation  setup  before  to  execution.  The  user  may  also 
modify  the  course  of  an  executing  simulation  by  stopping  the  simulation  and  changing  any  parameters. 

EXAMPLE:  Select  (or  change)  the  simulation  fidelity  for  a  particular  asset. 

1.3  POSTPROCESSING 

This  process  provides  detailed  tabular  and  graphical  output  about  the  simulation.  It  also  provides  post- 
processed  figures  of  merit.  The  output  is  available  at  the  user’s  terminal  or  on  paper  or  film  hardcopy. 

EXAMPLE:  Provide  graphical  output  on  all  side-B  weapon  trajectories. 

1.4  DISPLAY  RUN  TIME  DATA 

This  process  allows  the  user  to  request  the  display  of  various  data  so  that  she  may  observe  the  progress 
of  the  simulated  battle. 

EXAMPLE:  Display  trajectories  off  all  objects  in  space. 

1.5  LOG  DATA 

This  process  allows  the  user  to  request  the  logging  of  REAL-WORLD,  PERCEIVED -WORLDS,  SCE¬ 
NARIO,  EVENT.Q  and  other  useful  information.  This  information  is  written  to  a  postprocessing  file  during 
the  simulation. 
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1.  MANAGER 


MOR  -  SIMULATION  CODE  MANAGER 

1. 


FUNCTION  -  THIS  MODULE  18  THE  HIGHEST  LEVEL 

OF  CONTROL  FOR  THE  DETEC  SIMULATION.  IT  OBTAINS 
INPUT  FROM  THE  USER  AND  PASSES  IT  TO  THE 
VARIOUS  MAJOR  USER-INITIATED  FUNCTIONS. 

INPUT  -  NONE 

OUTPUT  -  NONE 


MGR  0 

INITIALIZE  FOR  THE  MANAGER 

DO  UNTIL  terminated  by  near 
GET  VALID  USER  COMMAND  (CMOS) 

CASE  (cad  type) 

WHEN  (scenario) 

GENERATE  AND  MODIFY  SCENARIO  (CMOS,  DISPLAYS)  /*1 . 1*/ 
WHEN  («atnp  |  interventions) 

SETUP  A  INTERVENTIONS  (CMDS,  DISPLAYS)  /*1.3*/ 

WHEN  (post) 

POSTPROCESSING  (CMDS,  DISPLAYS)  /*1.3*/ 

WHEN  (display) 

DISPLAT  RUN  TIME  DATA  (CMDS,  DISPLAYS)  /* 1.4*/ 

WHEN  (log) 

LOG  DATA  (CMDS,  DISPLAYS)  /*1.B*/ 

WHEN  (ran) 

/*2.  -  RUB  THE  SIMULATION*/ 

CALL  EXEC  (INTERRUPT) 

OTHERWISE 

SETUP  ERROR  RESPONSE  (CMDS.  DISPLAYS) 

END  CASE 

UPDATE  DISPLAY  (DISPLAYS) 

END  DO 

END  /*MGR*/ 


Level  1 


2.  EXEC 
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2.  EXECUTIVE 

The  executive  provides  overall  control  of  the  simulation  execution.  It  uses  a  list  of  time-ordered  events 
to  determine  which  functions  to  run  next. 

The  executive  resolves  any  conflicts  that  may  exist  in  the  simulation.  A  conflict  is  defined  as  the  case 
where  an  asset  functions  while  it  is  being  damaged  and/or  has  two  or  more  overlapping  performance  requests, 
where  the  asset  simulation  has  only  minimal  first-order  provisions  for  such  simulations.  The  provisions  are 
that  the  asset  simulation  modules  are  able  to  simulate  the  asset  performance  using  an  arbirary  length  time 
step  and  may,  in  addition,  be  able  to  use  modified  state  vectors  that  were  saved  during  the  conflict  period. 
For  example,  a  simulation  conflict  may  require  that  all  conflicting  assets  be  simulated  up  to  the  current 
time.  Another  possibility  is  that  conflicting  assets  be  simulated  using  discrete  time  steps  during  the  conflict 
interval.  For  the  case  of  the  saved  state  vectors,  the  saved  vectors  define  how  an  asset,  A,  is  being  damaged 
while  it  is  trying  to  damage  some  other  asset,  B.  The  simulation  then  uses  the  saved  state  vectors  for  A  to 
determine  the  extent  of  the  damage  to  asset  B. 

2.1  EXECUTIVE  CONTROLLER 

The  executive  controller  checks  for  interrupts  and  processes  EVENTs  from  the  EVENT.Q  in  order  by 
calling  other  EXEC  modules. 

2.2  DETECT  INTERRUPTS 

This  process  will  detect  interrupts  generated  by  the  user  during  execution  of  the  simulation. 

2.3  SAVE  STATE  VECTOR  IDENTIFICATION 

This  module  reviews  the  conflicts  of  a  particular  asset  and  determines  if  the  related  event  must  be  stepped 
or  if  it  can  be  in  save  state  vector  mode. 

2.4  CONFLICT  HANDLER 

This  module  determines  if  a  conflict  exists  for  the  event  that  is  to  be  executed.  If  a  conflict  exists,  this 
module  determines  how  to  resolve  the  conflict  and  puts  new  events  into  the  EVENT.Q  as  required.  The 
conflict  resolution  is  done  for  instantaneous  and  extended  events  as  described  in  the  following  paragraphs. 

Instantaneous  events  are  those  physical  activities  that  are  so  short  that  they  can  be  simulated  as  occurring 
in  an  infinitesimally  short  time.  This  module  performs  the  steps  necessary  to  initate  the  execution  of  the 
modules  needed  to  simulate  an  instantaneous  event  for  some  asset.  If  a  conflict  exists,  this  module  puts 
events  into  the  EVENT.Q  to  call  the  simulation  modules  to  resolve  the  conflict.  The  asset  simulations  are 
all  run  to  the  current  time,  and  then  the  asset  simulation  module  for  the  instantaneous  event  is  executed. 
Functions  that  are  already  in  step  mode  do  not  have  to  be  run  again  because  they  are  essentially  up  to  date. 

Extended  events  are  used  to  simulate  those  physical  activities  that  occur  over  a  substantial  time  span. 
This  module  performs  the  steps  necessary  to  initiate  the  execution  of  modules  to  start  and  end  the  simulation 
of  extended-time  activities  for  an  asset.  If  conflicts  exist  ,  this  module  puts  events  into  the  EVENT.Q  to 
call  the  simulation  modules  to  resolve  the  conflicts.  Conflicts  are  resolved  by  either  stepping  through  the 
conflict  period  using  discrete  time  steps  or  by  initiating  the  saving  copies  of  a  state  vectors  that  change 
during  the  conflict  period.  The  changed  state  vectors  will  be  used  by  conflicted  action  modules(s)  at  the 
end  of  the  extended  event  to  calculate  the  effect  of  the  conflict. 
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2.5  FIND  CONFLICTING  ASSETS 

This  module  identifies  events  that  ate  in  conflict  with  the  event  currently  being  set  up  for  execution  by 
the  executive.  The  identification  of  assets  from  extended-time  events  and  the  assets  that  they  affect  are 
stored  in  the  IN -PROGRESS  file.  This  process  will  determine  if  the  asset  identification  from  the  current 
event  is  already  in  the  file.  If  the  asset  is  in  the  file,  a  conflict  exists. 

2.6  CALL  MODULES 

This  module  selects  the  appropriate  simulation  module  to  execute  the  current  event. 
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2.  EXECUTIVE 


EXEC  -  SIMULATION  EXECUTION  CONTROL 

2.1 


FUNCTION  -  THIS  MODULE  WILL  SELECT  TIE  VEIT  EVENT  FROM 
THE  EVENT  QUEUE,  DETERMINE  IF  IT  IS  INSTANTANEOUS 
OR  EXTENDED  EVENT.  IT  PUTS  NEW  EVENTS  INTO  THE  EVEIT.Q 
TO  RESOLVE  CONFLICTS  AND  THEN  EXECUTES  THE 
ACTUAL  FUNCTION  REQUIRED  BT  THE  EVENT. 

CONFLICTS  ARE  RESOLVED  EITHER  BT  STEPPING 
THROUGH  THE  CONFLICTING  FUNCTIONS  OR  BT 
SAVING  CHANGED  STATE  VECTORS  AND  INTEGRATING  OVER 
THE  CHANGES  AT  THE  END  OF  THE  CONFLICT. 

INPUT  -  NONE 

OUTPUT 

INTERRUPT  -  THE  TYPE  OF  INTERRUPT  WHICH  TERMINATED 
THE  EXECUTIVE 


EXEC  CONTROLLER  (INTERRUPT) 

DO  UNTIL  INTERRUPT  «  COMPLETE  I  INTERVENE 
/*2.2  -  INTERRUPT  PROCESSING*/ 

CALL  IMTR  (INTERRUPT) 

IF  INTERRUPT  *  ND  INTR,  THEN 
IF  EVENTS  IS  EMPTY 
INTERRUPT  *  COMPLETE 
ELSE 

GET  BEIT  EVENT  FROM  EVENT -Q  (EVENT -DESC) 
ADVANCE  TIME  TO  TINE  FROM  EVENI-DESC 


IF  DOJIOV  (froa  event)  -  TRUE 
/*3.6  -  EXECUTE  EVENT*/ 

CALL  CMODULE  (EVENT  J) ESC) 

REMOVE  EVENT  FROM  EVENT -I)  (EVERT -DESC) 
ELSE 

/*3.4  -  RESOLVE  CONFLICTS*/ 

CALL  CONBAS  (EVENT -DESC,  DO -EVENT) 

IF  DO -EVENT  -  TRUE 

/*2.0  -  EXECUTE  EVENT*/ 

CALL  CMODULE  (EVENT -DESC) 

END  IF 
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2.  EXECUTIVE 


REMOVE  EVERT  FROM  EVERT. Q  (EVERT -DESC) 
END  IF 
END  IF 
END  IF 
END  DO 

END  /*EXEC*/ 


I NTS  -  INTERRUPT  PROCESSING 

2.2 


FUNCTION  -  THIS  MODULE  DETECTS  INTERRUPTS  FROM  THE  CODE 
USER  AND  RETURNS  THE  TYPE  OF  INTERRUPT 
TO  THE  CiLLING  MODULE 

INPUT  -  NONE 

OUTPUT 

INTERRUPT  -  THE  TYPE  OF  INTERRUPT  RECEIVED 


I NTS  (INTERRUPT) 

IF  an  lstampt  oe car rad,  THEN 
INTERRUPT  >  INTERVENE 
ELSE 

INTERRUPT  »  NO.INIR 
END  /*INTR*/ 


SSVID  -  SAVE  STATE  VECTOR  ID 
2.3 


FUNCTION  -  THIS  MODULE  DETERMINES  IF  THE  SPECIFIED  EVENT 
IS  A  SAVE  STATE  VECTOR  OR  STEP  TYPE 

INPUT 

EVE5T-DESC  -  POINTER  FOR  THE  EVENT  IN  QUESTION 
CONFLICT-LIST  -  LIST  OF  EVENTS  THAT  ARE  IN  CONFLICT 

OUTPUT 

SAVE.SV  ■  TRUE  -  EVENT  IS  SAVE  STATE  VECTOR 
*  FALSE  -  EVENT  IS  STEP 
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2.  EXECUTIVE 


SSVID  (EVENT-DESC,  CONFLICT  .LIST,  SiVE^V) 

if  conflict -lilt  li  empty,  thin 
error 

else 

do  for  each  event  In  conflict .list 
If  asset/event  li  s  savesv  type 
If  event  la  of  the  form  i  to  B 
i  must  be  stepped 
save-sv  -  false 
else 

4  can  be  save,ev  type 
savesv  -  true 
end  if 

else 

i  must  be  stepped 
savejiv  **  false 

end  if 
end  do 
end  if 

END  /*SSVID*/ 


COHHAN  -  CONFLICT  HANDLER 
2.4 


FUNCTION  -  THIS  MODULE  DETERMINES  IF  THE  ASSETS  INVOLVED 
IN  THE  EVENT  ARE  IN  CONFLICT  TITS  ANT  EVENTS.  IF  A 
CONFLICT  EXISTS,  APPROPRIATE  EVENTS  ARE  PUT  INTO  THE  EVENT.Q 
TO  RESOLVE  THE  CONFLICT. 

INPUT 

EVENT-DESC  -  THE  EVENT  BEING  PROCESSED 
OUTPUT 

DO VENT  -  TRUE  -  THE  DRIVING  EVENT  CAN  BE  EXECUTED 
-  FALSE  -  THE  EVENT  CANNOT  BE  EXECUTED 


CONHAN  {EVENT-DESC,  DO  .EVENT) 

/*2.6  -  GET  LIST  OF  CONFLICTING  EVENTS*/ 
CALL  CONFLT  (EVENT  J)ESC,  CONFLICT-LIST,  CONFLICT) 
IF  CONFLICT  -  TRUE,  THEN 
CASE  (MODE) 

THEN  (INSTANT) 
do-event  *  true 
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2.  EXECUTIVE 


0o  for  each  event  la  conflict -list 
if  event  it  enve  state  v*ctor  /*3.3*/ 
find  state  vtctor  In  real-world  (event -deec, 

state-vector) 

■ft  aavtJtv  *  trne  in  state  vector 

•lit 

put  event  into  events  to  do  nnconf licted  part 
of  newly  conflicted  event  nt  current  tine 
with  node  *  partial  and  do_nov  -  true 
d  o_e vent  *  false 
end  if 
end  do 

if  any  conflicting  event  it  stepped 4  then 

copy  instantaneous  event  folloving  the  event (e) 
jnet  added  to  svent-q  with  donov  »  tree 
/♦the  original  event  is  left  in  place*/ 
end  If 

WHEN  (BEGINNING) 

do  for  each  event  In  conf liet.list 
if  event  in  save  state  vector  /*2.3*/ 
find  etate  vector  in  real-world  (event  denc, 

state-vector) 

eet  save-tv  ■  trne  In  state-vector 

else 

if  conflicted  event  starts  at  same  tine  as 
beginning  event 

put  event  into  events  for  conflicted  event 
to  begin  step  with  node  *  flret-step 
and  do_now  ■  true 

else 

put  event  into  event _q  for  conflicted 

event  to  do  uac oaf licted  part  and  then  step 
with  node  *  step  and  do.now  *  true 
end  if 
end  do 

if  any  conflicting  event  is  stepped,  then 
copy  beginning  event  folloving  the  event (s) 
just  added  to  the  event_q  and  lit 
node  =  first-etep  end  donov  ■  true 
/♦the  original  event  Is  left  in  place*/ 
end  if 

add  iv.id(e)  to  in-progreoe 
DO  .EVENT  -  FALSE 
VHEI  (ENDING) 

do  for  each  event  in  conflict-list 

set  flag  nt  ending  event  of  aevly  nnconf licted  event 
to  do  last  tine  interval  (final  .event  _ptr) 
if  newly  nnconf licted  evente  are  stepped  ft 
they  no  longer  need  to  step,  then 


Level  1 


6-iI 


195 

100 

197 

190 

100 

200 

201 

202 

203 

204 

205 

200 

207 

200 

200 

210 

211 

212 

213 

214 

215 

210 

217 

218 

219 

220 

221 

222 

223 

224 

225 

220 

227 

228 

229 

230 

231 

232 

233 

234 

235 

230 

237 

238 

239 

240 

241 

242 

243 

6-12 


2.  EXECUTIVE 


find  i tip  * v«nt  in  ftvtnt^  and  remove 
t nd  if 
ind  do 

rftmovft  ftv_id(ft)  from  in .progress 
DO  EVENT  *  TRUE 
OTHERWISE 
DO  EVENT  =  TRUE 
END  CASE 
ELSE 

CASE  (MODE) 

WHEN  (INSTANT) 

DO  EVENT  *  TRUE 
WHEN  (BEGINNING) 

add  ftY-id  to  ia  progrftftft 
DO  EVENT  =  FALSE 
WHEN  (ENDING) 

remove  nv-ld  from  ln_progr»i» 

DO  EVENT  -  TRUE 
OTHERWISE 
DO  EVENT  -  TRUE 
END  CASE 
END  IF 

END  /*CDNHAH*/ 


CONFLT  ~  FIND  CONFLICTING  EVENT 
2,5 


FUNCTION  -  THIS  MODULE  SCANS  THE  LIST  OF  EXTENDED  EVENTS 
THAT  ARE  BEING  SIMULATED  AND  DETERMINES  IF  ANT  OF  THEM 
ARE  IN  CONFLICT  WITH  THE  NEW  EVENT. 

IT  RETURNS  A  LIST  OF  EVENTS  THAT  ARE  IN  CONFLICT  WITH 
THE  NEW  EVENT.  THE  NEW  EVENT  IS  IN  THIS  LIST. 

INPUT 

EVENT-DESC  -  THE  EVENT  DRIVING  THIS  ACTIVITT 
OUTPUT 

CONFLICT. LIST  -  A  LIST  OF  ALL  THE  EVENTS  AND  ASSETS  THAT 
ARE  IN  CONFLICT  WITH  THE  NEW  EVENT 
CONFLICT  -  TRUE  -  i  CONFLICT  HAS  BEEN  FOUND 

*  FALSE  -  VO  CONFLICT  HAS  BEEN  FOUND 


CONFLT  (EVENT-DESC,  CONFLICTXIST,  CONFLICT) 
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3.  EXECUTIVE 


CONFLICT  -  FALSE 

do  1  ■  1  to  nnrnbar  of  aatriae  la  la. progroat 

If  say  tv  .Id  froa  now  avant  ■  av.id(i)  froa  ia-prograae 
coafliet  “  trao 

If  tpaeo  It  avallablt  ia  coafllct-llet 

copy  in. prograta  oatry  1  to  next  locatloa  la  coafliet .lltt 
alto 
arror 
and  if 
and  do 

END  /‘CONFLI*/ 


CM0DULE  -  CALL  FUNCTIONS  FOE  EXEC 
2.6 


FUNCTION  -  THIS  MODULE  WILL  CALL  THE  SPECIFIED  MAJOR  MODULE 
AS  DEFINES  BT  THE  INPUT  PARAMETER. 


INPUT 

EVENT-DESC  -  STRUCTURE  WHICH  POINTS  TO  EVENT  SATA 
FOR  THE  MODULE  BEINO  CALLED 


OUTPUT  -  NONE 


C MODULE  (EVENT-DESC) 

CASE  (DESTINATION) 
vnEN  (an  id) 

/•3.  -  ORDERLY  EVOLUTION  OF  REAL  VORLD  OBJECTS*/ 

MOTHER  NATURE  (EVENT SESC) 

WHEN  (ba  id) 

/*4. 1  -  DO  DECISION  MAKING  FOR  ASSETS*/ 

BATTLE  MANAGERS  (EVENT-DESC) 

WHEN  (an  id) 

/* 4.2  -  CALCULATE  SENSOR  FUNCTIONING*/ 

SENSORS  (EVENT-DESC) 

VHEN  (ca  id) 

/*4 .3  -  CALCULATE  COMMUNCIATION  BETWEEN  ASSETS*/ 

COMMUNCIATIONS  (EVENT J) ESC) 

WHEN  («p  id) 

/*4.4  -  CALCULATE  WEAPON  FUNCTIONING*/ 

WEAPONS  (EVENT-DESC) 

WHEN  (ap  id) 

/*4 .6  -  INTERACTIONS  BETWEEN  ASSETS*/ 
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3.  EXECUTIVE 


303  EVENT  PHYSICS  (EVENT  DESC) 

304  WHEN  (lg  Id) 

305  /« 5.  -  DUMPS.  LOGS  AND  DISPLAYS*/ 

390  LOCOES  (EVENT. DESC) 

307  OTHERWISE 

308  ERROR 

300  END  CASE 

300  END  /*CMODULE*/ 
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3.  MOTHER  NATURE 
Level  1  Data  Flow 


EVENT-Q 


REAL-WORLD 
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S.  MOTHER  NATURE 


3.  MOTHER  NATURE 

31  MOTHER  NATURE  CONTROLLER 

The  Mother  Nature  Controller  performs  three  functions: 

1)  It  decodes  the  EVENTDATA  to  determine  which  updates  to  perform* 

2)  It  performs  the  control  functions  necessary  to  accomplish  the  updates, 

3)  It  constructs  and  emplaces  EVENT*  in  the  EVENT-Q  for  periodic  updates. 

3.2  STATE  VECTOR  UPDATES 

This  is  a  set  of  modules,  each  of  which  updates  a  class  of  state  vec  tors.  The  updates  may  include  position, 
velocity,  orientation  and  other  geometrical  type  variables  as  well  as  conditions  such  as  temperature  and  fuel 
remaining. 

3.3  GRID  QUANTITY  UPDATES 

This  is  a  set  of  modules,  each  of  which  updates  a  grid  variable,  such  as  electromagnetic  environment  or 
the  nonlocal  weather.  The  local  weather  (storms)  is  treated  on  the  basis  of  individual  entities  described  by 
state  vectors  and  updated  by  the  State  Vector  Updates  modules. 
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4.  ENGAGEMENT 
Level  1  Data  Flow 


REAL-WORLD 
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4.  ENGAGEMENT 


4.  ENGAGEMENT 


4.1  BATTLE  MANAGERS 


A  Battle  Manager  uses  information  sent  to  it  by  sensors,  weapons,  and  other  battle  managers,  along  with 
self-generated  information  and  information  loaded  during  the  initialization  process  to  make  decisions  and 
send  messages  based  on  those  decisions.  All  of  the  above  information  is  stored  in  a  battle  manager’s  own 
perceived  world  -  no  other  information  is  available  for  the  decision  process. 


4.2  SENSORS 


A  Sensor  functions  as  a  filter  on  real-  and  perceived- world  data.  It  can  function  either  periodically  or 
under  explicit  orders  and  send  messages  about  what  it  has  sensed  to  battle  managers. 


4.3  COMMUNICATIONS 


This  process  simulates  the  communication  between  various  assets  used  by  the  simulation.  In  some  cases 
routing  decisions  may  be  made.  Also,  environmental  effects  are  accounted  for. 


4.4  WEAPONS 


A  weapons  module  calculates  the  actual  function  of  a  weapon,  e.g.,  nuclear  yield  for  a  bomb,  beam 
duration  and  intensity  for  a  laser,  etc. 


4.5  EVENT  PHYSICS 


The  Event  Physics  module(s)  calculates  the  interaction  between  a  directed  attack  and  a  specific  target 
(e.g.,  laser  on  a  RV),  calculates  the  effects  of  volume  stresses  on  nearby  assets  (e.g.,  blast  on  a  radar  antenna), 
and  performs  the  creation  and  destruction  of  state  vectors  (e.g.,  solar  flares,  spawn  RV,  volcanic  eruption, 
etc.). 
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5.  LOGGER 
Level  1  Data  Flow 


EVENT- DESC 


EVENT-DATA 
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DISPLAYS 
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6.  LOGGER 


5.  LOGGER 

5.1  LOGGER  CONTROLLER 

This  module  decides  which  modules  to  run  by  using  information  from  EVENT  .DATA. 

5.2  OUTPUT  FOR  POSTPROCESSING 

This  module  dumps  interesting  information  from  the  SCENARIO,  EVENT.Q,  REAL-WORLD,  and 
PERCEIVED -WORLDS  files.  This  information  can  then  be  reduced  and  analysed  after  the  simulation 
run  by  using  the  postprocessing  functions. 

5.3  OUTPUT  FOR  RESTART 

This  module  makes  an  exact  copy  of  all  necessary  files  so  the  simulation  can  be  restarted  from  this  exact 
point  at  some  later  time  if  desired. 

5.4  UPDATE  ACTIVE  DISPLAY(S) 

This  module  will  update  any  active  displays  that  have  been  selected  by  the  user.  This  allows  the  user  to 
observe  the  progress  of  the  simulation. 

5.5  BUILD  EVENT  FOR  NEXT  OUTPUT 

This  module  decides  how  long  until  the  next  output  is  required  and  generates  the  EVENT  that  will  call 
LOGGER  at  the  proper  time.  The  EVENT  is  then  added  to  the  EVENT.Q. 

5.6  LOG  OUTPUT 

This  module  logs  what  the  LOGGER  function  has  done  during  this  particular  call. 
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S.  LOGGER 


LOGGER  -  DO  RUN  TIME  OUTPUT 

6.1 


FURCIIOR  -  THIS  MODULE  CALLS  THE  VARIOUS  OUTPUT  FUNCTIONS 
THAT  CAH  BE  USED  WHILE  THE  SIMULATOR  IS  RURRIRG. 

IT  ALSO  DECIDES  VHEI  THE  VEIT  OUTPUT  IS  REEDED  AND 
GENERATES  AR  EVERT  SO  THAT  IT  WILL  BE  CALLED  AT  THE 
APPROPRIATE  TIME. 

INPUT 

EVENT  J)ESC  -  THE  EVENT  THAT  TRIGGERED  THE  CALL 
OUTPUT  -  RORE 


LOGGER  (EVERT J) ESC) 

GET  EVERT  FROM  EVENT -Q  ( EVENT  J)  ESC,  EVERT. DATA) 

CASE  () 

WHEN  (poetproceaelng) 

OUTPUT  FOR  POST  PROCESSING  (EVENT-DATA)  /*5.2*/ 
WHEN  (raatart) 

OUTPUT  FOR  RESTART  (EVENT-DATA)  /*6.3*/ 

WHEN  (die play) 

UPDATE  ACTIVE  DISPLAYS  (EVENT -DATA)  /*6.4*/ 
OTHERWISE 
ERROR 
END  CASE 

BUILD  EVERT  FOR  NEXT  OUTPUT  AND  ADD 
TO  EVERT-0  (EVENT -DESC)  /*6.6*/ 

LOG  OUTPUT  (EVERT .DESC)  /* 6.6*/ 

END  /‘LOGGER*/ 
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7.  LEVEL  2  &  3  DATA  FLOW  AND  DESCRIPTIONS 


Mother  Nature 
Battle  Manager 
Sensors 

Communications 
Weapons 
Event  Physics 
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3.1  MOTHER  NATURE  CONTROLLER 
Level  2  Data  Flow 
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3.2  MOTHER  NATURE  STATE 
VECTOR  UPDATES 
Level  2  Data  Flow 


level  2  &  3 


3.3  MOTHER  NATURE  GRID 
QUANTITY  CALCULATIONS 
Level  2  Data  Flow 
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7.  LEVEL  2  &  3  MOTHER  NATURE 


3.1  MOTHER  NATURE 

3.1.1  GET  EVENT JJATA 

This  is  s  standard  module  that  uses  the  EVENT  -DESC  to  fetch  the  EVENT  -DATA. 

3.1.2  CALL  MODULES 

This  module  uses  the  EVENT  .DATA  to  identify  which  classes  of  STATEVECTORs  and  GRID. 
QUANTITY(ies)  require  updating  or  calculating,  and  calls,  in  turn,  the  correct  modules  to  do  the  calcula¬ 
tions.  It  may  receive  information  from  the  modules  ou  when  they  should  be  recalculated,  and  it  writes  this 
information  in  the  MN .EVENT .PARAMETERS  file. 

3.1.3  DETERMINE  AND  CONSTRUCT  EVENT 

This  module  analyses  the  data  in  the  MN -EVENT  .PARAMETERS  file  to  determine  when  and  how 
Mother  .Nature  should  be  called  again.  It  then  constructs  the  necessary  EVENTs  and  puts  them  in  the 
EVENT.Q. 

3.2.1  CLASS  n  S  TATE  .VECTOR  UPDATE  MODULE 

This  is  a  set  of  update  modules,  one  for  each  class  of  STATE  .VECTORS.  Each  uses  the  existing  para¬ 
metric  description  within  the  STATE  .VECTOR  to  calculate  new  values  of  a  set  of  variables  for  the  current 
time. 

3.2.2  GET  STATE  VECTORS 

This  module  gets  from  the  REAL  .WORLD  all  STATE.VECTORs  with  the  SV  .CLASS  JD. 

3.2.3  STORE  STATE.VECTORs 

This  module  stores  the  updated  STATE.VECTORs  in  the  appropriate  places  in  the  REAL.WORLD. 

3.3.1  GRID  QUANTITY  CALCULATIONS 

Thu  represents  a  set  of  modules,  each  of  which  does  the  calculations  of  a  GRID  .QUANTITY  (e.g. 
electromagnetic  environment  or  nonlocal  weather)  for  a  specific  time,  and  for  all  grid  locations.  It  uses  the 
source  STATE.VECTORs  and  GEOGRAPHY  put  in  the  MN  .SOURCE  and  MN  .GEOGRAPHY  files  by 
Get  State  Vectors  and  Store  State  Vectors  and  ships  the  calculated  quantities  to  Store  Grid  Quantities  for 
storage. 

3.3.2  GET  STATE.VECTORs 

This  module  gets  from  the  REAL.WORLD  all  STATE.VECTORs  with  a  specific  SV.CLASSJD  and 
writes  them  to  the  MN  .SOURCES  and  MN.GEOGRAPHY  files. 

3.3.3  GEOGRAPHY 

This  module  gets  from  the  REAL.WORLD  whatever  GEOGRAPHY  information  has  been  requested 
by  Grid  Quantity  Calculations  using  the  parameter  MN  .GEOGRAPHY .REQUEST  and  writes  it  in  the 
MN -SOURCES  and  MN.GEOGRAPHY  files. 
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7.  LEVEL  3  &  3  MOTHER  NATURE 


3.3.4  STORE  GRID  QUANTITIES 

This  module  accepts  GRID  .QUANTITY  and  writes  it  to  the  appropriate  place  in  the  REAL  WORLD 
file. 
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7.  LEVEL  3  &  3  MOTHER  NATURE 


MV  -  MOTHER  NATURE 
3.1 


FUNCTION  -THIS  MODULE  GETS  THE  EVENT  FOR  THE  MOTHER  NATURE 
MODULES,  CALLS  THE  VARIOUS  MODULES  AND  CONSTRUCTS  THE 
EVENTS  FOR  THOSE  MODULES  RE<)UIRIBO  CALLS  TO  DO  PERIODIC 
OR  ADDITIONAL  MOTHER  NATURE  CALCULATIONS. 

INPUT 

EVES T-D ESC  -  THE  EVENT  THAT  TRIGGERED  THE  CALL 

OUTPUT 

NONE 


MN  (EVENT-DESC) 

GET  EVENT  FROM  EVENT J(  (EVENT  DESC,  EVENT-DATA)  /*3.1.  W 
DETERMINE  FROM  EVENT  .DATA  THE  MODULES  TO  BE  CALLED 
DO  FOR  EACH  MODULE  TO  BE  CALLED 
CALL  aodele  (TIME,  NE1T.TIME,  MN -AGAIN)  /*3.1.3*/ 

IF  MB .AGAIN  *  TRUE 

WRITE  NEXT-TIME  k  SV.ID  TO  MB -EVENT -PARAMETERS 
END  IF 
END  DO 

ANALYZE  ENTRIES  IN  MN  -EVENT  -PAR  AMETOS 
DETERMINE  AND  CONSTRUCT  EVENTS  /*3.1.3*/ 

END  DO 
END  /*MN*/ 


MNSYUP  -  MOTHER  NATURE  STATE  VECTOR  UPDATE 
3.3 


FUNCTION  -  THIS  IS  A  SERIES  OF  MODULES  EACH  OF  WHICH  UPDATES 
A  CLASS  OF  STATE  VECTORS  SUCH  AS  POSITION,  VELOCITY,  AND 
FUEL  RBUININO. 

INPUT 

EVENT-DATA  -  THE  EVENT  WHICH  TRIGGERED  THE  MODULE  CALL 
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7.  LEVEL  2  &  3  MOTHER  NATURE 


OUTPUT 

VEXT-TIME  -  THE  TIME  VHE8  THIS  MODULE  IS  TO  BE  CALLED  AO A II 
MI-AGAII  -  TKUE  -  CALL  THIS  MODULE  MI-AQAII 

-  FALSE  -  DO  IOT  CALL  THIS  MODULE  MI-AQAII 


MISVUP  (EVEIT-DATA,  VEXT-TIME,  MI-AGAII) 

GET  ALL  STATB.VECTOES  FROM  REAL -WORLD  FOE  SV -CLASS-ID  /«3.2.2*/ 
DO  FOE  EACH  EETEIEVED  STATE-VECTOR 

UPDATE  THE  STATE-VECTOR  (EVEIT-DATA,  STATE-VECTOR)  /*3.2.1*/ 
END  DO 

STORE  ALL  THE  MODIFIED  STATE-VECTORS  INTO  REAL  VORLD  /*3.2.3*/ 
If  aodala  aaada  to  ran  again 
conpnta  NEXT-TIME 
MI-AQAII  -  TRUE 

alaa 

MI-AGAII  -  FALSE 
and  if 

BID  /*MNSVUP*/ 


MNGRID  -  MOTHER  IATURE  GRID  QUAITITT  CALCULATIONS 
3.3 


FUNCTION  -  THIS  IS  A  SET  OF  MODULES  EACH  OF  WHICH 
UPDATES  A  GRID  VARIABLE  SUCH  AS  ELECTROMAGNET 
ENVIRONMENT  OR  THE  NOI  LOCAL  WEATHER. 

INPUT 

EVENT-DATA  -  THE  EVENT  WHICH  TRIGGERED  THE  MODULE  CALL 
OUTPUT 

NEXT-TIME  -  THE  TIME  WHEN  THIS  MODULE  IS  TO  BE  CALLED  AGAIN 
MI-AGAII  -  TRUE  -  CALL  THIS  MODULE  MI-AGAII 

-  FALSE  -  DO  IOT  CALL  THIS  MODULE  MI-AGAII 


MNGRID  (EVEIT-DATA.  NEXT-TIME,  MI-AGAII) 

GET  ALL  STATE  VECTORS  FROM  REAL-WORLD  FOR  SV  .CLASS-ID  /*3.3.2*/ 
WRITE  RETRIEVED  STATE-VECTORS  TO  MI -SOURCES 

GET  GEOGRAPHY  FOR  MI -GEOGRAPHT -REQUEST  FROM  REAL-WORLD  /*3.3.3*/ 
WRITE  RETRIEVED  GEOGRAPHT  TO  MI  .GEOGRAPHT 
DO  FOR  EACH-GRID  QUAITITT 

CALL  nodnla  TO  CALCULATE  VARIABLE  GRID  QUAITITT  /*3.3.1*/ 

STORE  CRID-QUANTITT  INTO  REAL-WORLD  /*3.3.4*/ 
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7.  LEVEL  3  &  S  MOTHER  NATURE 


07  EHD  00 

08  if  modal*  n**4*  to  bo  ns  mgmim 

00  compote  BEXT.TIME 

100  MI.AG4II  ■  TRUE 

101  olmo 

102  MI -AQAIJ1  -  FALSE 

103  end  if 

104 

105  EHD  /♦HUGE ID*/ 
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4.1  BATTLE  MANAGER 

4.1.1  BATTLE  MANAGER  CONTROLLER 

There  is  a  battle  manager  for  every  asset  that  is  required  to  make  any  decisions  and/or  report  results. 
The  controller  process  gets  data  for  the  battle  manager  processes  and  determines  which  processes  to  call. 

4.1.  I  n  DETERMINE  BATTLE  MANAGER  CAPABILITY 

This  process  determines  what  is  required  of  the  battle  manager  in  the  execution  of  this  event.  Based 
on  the  battle  manager’s  state  vector  and  perceived  world  information,  this  process  determines  if  the  battle 
manager  is  capable  of  performing  its  function. 

4.1.2. D  INITIAL  REVIEW  OF  PACKET 

This  process  gets  all  data  that  may  be  received  at  this  time  and  may  perform  a  cursory  first  review  of 
the  data,  including  consistency  and  applicability  checks. 

4.1.3. n  ANALYZE/EVALUATE  OPERATIONS 

This  process  examines  the  battle  manager’s  perceived  world  and  other  data  and  performs  analyses  and 
evaluations  of  the  current  and/or  projected  situation.  This  can  be  triggered  by  the  reception  of  unexpected 
information,  the  reception  of  information  for  an  existing  operation,  an  interruption  for  an  existing  operation, 
or  a  self-triggered  evaluation.  At  this  time  the  battle  manager  may  record  its  observations  in  its  perceived 
world. 

4.1.4. n  DETERMINE  NEXT  OPERATION 

Based  on  the  above  analysis,  the  battle  manager  may  decide  to  start  a  new  operation,  continue  an  existing 
operation,  or  terminate  an  operation.  This  process  generates  the  EVENTs  and  PACKETS  required  to  do 
this  and  may  record  the  battle  manager’s  decisions  in  its  perceived  world. 
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1 

2 

3 

4  . . . . . . . 

6  bm  -  battle  manager  for  generic  function 

6  4.1.1 

7  - - - - - — 

3 

9  function  -  Tile  nodule  le  auppoeed  to  give  a  rough 

10  idea  of  hoy  a  real  battle  manager  will  nee  the  data 

11  and  the  type  of  control  required. 

12 

13  input 

14  event-deac  -  pointer  to  the  event  driving  the  battle  manager 
lb 

10  output  *  none 

17 

18  . . . 

19  bm  (event .dee c) 

20 

21  get  event  from  event  _q  (event  -dee  e,  event  .data) 

22  get  battle  manager  at  at  e-vector  from  realtor  Id 

23  extract  damage  from  bm  atate_vector 

24  If  damage  *  dead,  then 

25  log  receipt  of  event  for  dead  an eat 

26  alee  /*aneet  may  be  functioning*/ 

27  If  event -data  indicate!  a  packet  accompanies  the  event,  then 

28  get  packet  from  info-packet  a  (event-data,  packet) 

29  end  if 

30  extract  epecific  module  number  from  event-data 

31  caee  (mode) 

32  vh  en  (f ir at  a  t  ep ) 

33  if  time  of  next  a tap  <  time  of  final  event 

34  build  event  for  fir at  etep  (event -data) 

35  put  into  event-q  (event-data) 

36  end  if 

37  when  (partial  |  etep  |  laet-atep  I  instant) 

36  if  module  le  need,  then 

39  determine  battle  mgr  capability  (event -data, 

40  <pecket ,  etate- vector ,  ok)  /*4.1*l.n*/ 

41  /*  <xxx>  indlcatee  an  optional  parameter*/ 

42  end  if 

43  If  ok  *  true  /*if  bm  hes  capability  to  continue*/ 

44  Jt  module  la  need,  thaa 

46  Initial  review  of  data  (event-data, <packet>,  etate  vector ,  ok) 

46  /*4.1.2.a*/ 

47  end  if 
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If  ok  ■  traa  /*if  data  satisfied  tka  Initial  ravlsv*/ 
k  nodal#  in  nnad,  than 

naalyia/avaliata  oparationa  (avast. data,  < packet >, 

state. vector,  racordad -daclaloa,  ok)  /*4.1.3.n*/ 

and  if 

if  ok  ■  tna  /*if  bn  aaada  to  contiana  thin  operation*/ 
k  nodal#  in  nnad,  than 
datarnlna  next  aparation  (atata.vactor, 

racordad. daeiaion)  /*4 .1.4, n*/ 
if  Cioda  ■  atop  k  cal ea Inti on  *111  continna  k 
tlaa  of  aaxt  otap  <  tiaa  of  finals  vast) 
bnlld  avast  for  saxt  atop  (avast .data) 
pat  into  event  .q  (avast .data) 
and  if 
ala* 
arror 
and  if 
otherwise 
arror 
and  caaa 
and  if 

and  /*b**/ 
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4.2  SENSORS 

4.2.1  SENSORS  CONTROLLER 

This  module  does  the  followup  gets  the  EVENT -DATA  appropriate  to  the  EVENT-DESC,  and  analyses 
the  EVENT-DATA  to  determine  the  SENSOR  -OPERATING  .PARAMETERS  and  a  specific  sensor  ID.  It 
performs  the  control  functions  to  call  the  other  modules  within  Season. 

4.12  FILTER 

This  is  one  of  a  set  of  modules  that  uses  the  SENSOR-OPERATING  PARAMETERS  and  object 
STATE-VECTORs  to  determine  which  objects  are  viewable  by  a  particular  sensor.  The  viewable  STATE- 
VECTORs  are  written  to  the  VIEWABLE.OBJECTSXIST. 

4.2.3  SENSOR  VIEWING  SIMULATION 

This  is  one  of  a  set  of  modules,  each  of  which  simulates  the  functioning  of  a  specific  sensor  type.  It  uses 
condition  parameten  from  the  appropriate  installation  STATE-VECTOR  along  with  ENVIRONMENT  and 
possibly  GEOGRAPHY  to  determine  the  appropriate  perception  of  each  object  in  the  viewable  objects  list. 

4.2.4  EVENT  /  PACKET  CONSTRUCTION 

This  is  a  set  of  modules,  one  for  each  sensor  type,  which  does  the  following-. 

1)  performs  routine  analysis  (analysis  not  requiring  a  Battle  Manager)  of  the  pereeived  data,  e.g.,  sorts  the 
objects  according  to  whether  on  not  they  match  a  predetermined  signature, 

2)  constructs  the  PACKET(s)  to  be  transmitted  to  Battle  Manager(s), 

3)  constructs  an  EVENT  for  the  transmission  to  be  accomplished,  and 

4)  writes  the  PACKET  and  EVENT  to  the  appropriate  files. 
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ie 
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SENSOR  -  SIMULATE  SENSORS 
4.2.1 


FUNCTION  -  A  SENSOR  FUNCTIONS  AS  4  FILTER  ON  RE AL¬ 
AND  PERCEIVED -WORLD  DATA,  SENSORS  MAT  OPERATE  PERIODICALLY* 
CONTINUOUSLY*  OR  UPON  COMMAND. 

INPUT 

EVENT J3ESC  -  THE  EVENT  DRIVING  THIS  ACTIVITY 

OUTPUT 

NONE 


SENSORS  (EVENT -DESC) 

gat  avant  froa  avantq  (avant  jd  sac,  avant -data) 
git  still  or  it  its. vsctor  from  rial  .world 
sxtraet  daaagi  from  aantor  itatavactor 
if  daaagi  *  dsad4  thin 

log  ncilpt  of  avant  for  diad  amt 
ilii  /*asiat  may  bi  functioning*/ 

ixtract  ipiclfic  moduli  number  froa  event -data 
can  (modi) 

whin  (firit-itip) 

if  tiao  of  naxt  itip  <  tiai  of  final  event,  thin 
build  iviat  for  first  itip 
put  Into  event  .q  (event -data) 
and  if 

whan  (partial  |  itap  |  last  itap  |  instant) 

/♦4 . 2.2  -  determine  If  object  la  viewable*/ 
call  filtar  (itate.vaeto r,  avant) 

/*4.2.3  *  do  ion tor  visaing  simulation*/ 
call  iYi  (itati-vactor ,  SYint) 

/*4.2.4  -  construct  packet  and  event*/ 
call  pac  (state-vector,  avant) 
if  aoda  *  itap  *  calculation  la  to  contlnna  k 
tlaa  of  naxt  itap  <  tiaa  of  final  avant 
build  avant  for  naxt  itap  (avant .data) 
put  into  event  ^q  (avant -data) 
and  if 
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otharviaa 
arror 
and  cm 
•  nd  If 

END  /  *SEN50R*/ 


FILTER  ~  DETERMINE  IF  OBJECT  IS  VIEliBLE 
4*2.2 


FUNCTION  -  THIS  MODULE  USES  THE  SENSOR  OPERATING  PARAMETERS 
AND  OBJECT  STATE  VECTORS  TO  DETERMINE  WHICH  OBJECTS 
ARE  VIEWABLE  BT  THE  SENSOR .  THE  VIEWABLE  OBJECTS1 
STATE- VECTORS  ARE  WRIT  TEN  TO  THE  VIEWABLE -OBJECT  LIST  FILE. 

INPUT 

STATE-VECTOR  -  SENSOR  STATE-VECTOR 
EVENT  *  THE  EVENT  DRIVING  THIS  ACTIVXTT 

OUTPUT 

NONE 


FILTER  (STATE-VECTOR ,  EVENT) 

gat  aanaor  operating  paramatara  from  avant-data 
find  vlawabla  tact ora  for  ••aiorop«rtt  ing  pa  ran*  tors 
do  for  each  viavabla  o actor 

do  for  aaeh  objaet  ia  soctor  for  claaa  of  intarost 
(at  atata -Victor  for  objact  from  real .world 
calculate  if  vlavabla 
if  vlavabla.  than 

writi  object' a  atata_vactor  to  viavabla-objact-llat 
and  if 
and  do 
and  do 

do  background  for  filtar 

vrita  background  aonreaa  to  viavable-objactLlat 
END  /*FILTER*/ 


SVS  -  SENSOR  VIEWING  SIMULATION 
4.2.3 
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LEVEL  3tS  SENSORS 


FUNCTION  -  THIS  MODULE  USES  THE  SENSOR  STATE,  VECTOR  ALONG 
II TH  ENVIRONMENT  AID  PERHAPS  GEO  GRAPH!  TO  DETERMINE 
THE  APPROPRIATE  PERCEPTION  OF  A I  OBJECT. 

INPUT 

STATE-VECTOR  -  SENSOR  STATE-VECTOR 
EVENT  -  THE  EVENT  FOR  THIS  ACTIVITT 

OUTPUT 

NONE 


SVS  (STATE-VECTOR,  EVENT) 

gat  aanaor-opsratlng-paraaatsro  from  avant-data 
If  othar  parameter •  art  needed 

gat  additional  •  an  aor  .operating  parana  tar  a  from  at ate. vector 
and  If 

do  for  each  objact  in  viewible-object-llst 

do  viaving  simulation  to  product  parcalvad-attrlbntaa 
writs  perceived -attributes  to  parcel  ved.object^attribntei 
and  do 

do  aanaor  background  simulation 

writs  background  to  pare eivedobj  act ^attributes 

END  /*SVS a/ 


PEC  -  CONSTRUCT  PACKET  AND  EVENT 
4.2.4 


FUNCTION 

THIS  MODULE  CONSTRUCTS  ANT  PACKET  APPROPRIATE  FOR  THIS 
EVENT,  AID  CONSTRUCTS  AND  STORES  AN  EVENT  TO  SEND  THE  PACKET. 

INPUT 

STATE-VECTOR  -  THE  STATE  .VECTOR  OF  A  PARTICULAR  SENSOR 
EVENT  -  rm  EVENT  DRIVING  THIS  ACTIVITT 

OUTPUT 

NONE 


PEC  (STATE-VECTOR,  EVENT) 
determine  if  a  packat  ia  to  ba  aant 
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if  a  packet  la  to  ba  aait 
conatrnct  the  packet 
■tore  the  packet  in  INFO  PICKETS 
conatrnct  the  EVENT  to  aend  the  PICKET 
pat  the  EVENT  la  the  EVENT-1) 
end  If 

if  eeaaor  neede  to  ran  again 
build  event  to  reatart  eeaaor  Caveat,  data) 
pat  into  event.q  (event-data) 
end  if 

END  /*PEC*/ 
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4.3.3  COMMUNICATIONS 
CALCULATE  PATH  FUNCTIONS 
Level  3  Data  Flow 
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LEVEL  2  &  S  COMMUNICATIONS 


4.3.1  COMMUNICATIONS  CONTROLLER 

Thb  process  does  the  overall  control  of  the  commiinci&tion  function. 

4.3.2  TRANSMITTER  TRANSFER  FUNCTION 

This  is  a  series  of  modules,  each  of  which  represents  a  type  of  transmitter.  Each  module  uses  the 
STATE  .VECTOR,  including  damage  parameters  for  a  particular  transmitter  installation,  to  transform  the 
INTENDED  JACKET  into  the  TRANSMITTED  JACKET.  The  TRANSMITTED  JACKET  may  include 
parametric  transmission  characteristics  such  as  frequency,  antenna  pattern  type,  power  level,  signal-to-nobe 
ratio,  and  transmitter  location.  At  some  fidelity  levels,  the  transmitter  module  functions  may  depend  on 
ENVIRONMENT  data  from  REAL. WORLD. 

4.3.3  CALCULATE  PATH  FUNCTION 

This  module  computes  the  transform  for  the  communciation  path.  For  multiple  paths  to  the  same 
receiver,  a  composite  transform  is  completed. 

4.3.4  APPLY  PATH  FUNCTION 

The  module  does  the  actual  convolution  of  the  path  transfer  function  with  a  TRANSMITTED  JACKET 
to  give  an  INCIDENT  JACKET. 

4.3.5  RECEIVER  TRANSFER  FUNCTION 

This  is  a  series  of  modules,  each  re  presen  tat  in  g  a  type  of  receiver.  Each  module  uses  the  STATE-VECTOR, 
including  damage  parameters  for  a  particular  receiver  installation,  to  transform  the  INCIDENT-PACKET 
into  the  RECEIVED  JACKET.  At  some  fidelity  levels,  the  receiver  module  function  may  depend  on  ENVI¬ 
RONMENT  data  from  REAL-WORLD. 

4.3.3.1  CHECK  FOR  NEW  SOURCES 

Thb  module  determines  if  some  new  sources  have  become  active  that  will  affect  the  communciations 
simulation.  If  thb  is  true,  it  will  be  necessary  to  recompute  the  path  transfer  function. 

4.3.3.2  DETERMINE  TRANSMITTER  CHARACTERISTICS 

Thb  b  a  series  of  modules,  one  for  each  type  of  transmitter.  A  module  determines  the  characteristics 
for  a  particular  transmitter.  This  b  then  used  to  calculate  routing  and  receive  times. 

4.3.3  3  LOOK  FOR  INTENDED  RECEIVERS 

Thb  module  sets  up  the  matrix  which  defines  the  receivers  and  the  paths  to  those  receivers  for  thb 
particular  transmission. 

4.3. 3. 4  CALCULATE  RECEPTION  TIMES 

Thb  module  calculates  a  vacuum  reception  time  for  each  receiver  identified  by  the  CONNECTIVITY. 
MATRIX.  An  event  is  generated  for  each  receiver  to  simulate  the  reception  of  the  message,  and  the  event  b 
put  into  EVENT .Q. 
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4.3.S.5  PATH  TRANSFER  FUNCTION 

This  module  computes  the  transform  for  the  communciation  path,  including  composite  transforms,  when 
required. 
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COMM  -  COMMUNICATIONS 
4.3.1 


FUNCTION  -  THIS  FUNCTION  SIMULATES  COMMUNICATIONS 
BETWEEN  Visions  ASSETS  USED  IN  THE  SIMULATION . 
MULTIPATH  EFFECTS  WILL  BE  SIMULATED. 
ENVIRONMENTAL  EFFECTS  ARE  ALSO 
ACCOUNTED  FOR.E.O.,  WEATHER.  NUCLEAR. 

INPUT 

EVENT.DESC  -  THE  EVENT  DRIVING  THIS  ACTIVITY 

OUTPUT 

RONE 


CONN  (EVENT  JJESC) 

GET  EVENT  FROM  EVENT J)  (EVEST.DESC.  EVENT-DATA) 

If  this  la  a  tranaalt  event,  than 

/*4.3.a  -  transmitter  tranafer  function*/ 
call  ttf  (avant) 

/*4.3.3  -  Cftlcnlata  path  fnnctiona*/ 
call  cpf  (avant) 
alaa  /*racaiva  avant*/ 

/*4, 3. 3  -  calcnlata  path  fnnctiona*/ 
call  cpf  (avant) 

/*4.3.4  -  apply  path  function*/ 
call  apf  (avant,  Incident-packet) 

/*4.3.5  -  racaivar  tranafar  function*/ 
call  rtf  (avant,  incident  packat) 
and  if 

END  /*CDMM*/ 


TTF  -  TRANSMITTER  TRANSFER  FUNCTION 
4.3.3 


FUNCTION  -  THIS  MODULE  USES  THE  TRANSMITTER  STATE-VECTOR 
INCLUDING  DAMAGE  PARAMETERS  TO  TRANSFORM  AN 
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INTENDED -PACKET  INTO  THE  TRANSMITTED  PACKET. 
INPUT 

EVENT  -  THE  EVENT  DftIVINO  THIS  ACTIVITY 

OUTPUT 

NONE 


TTF  (EVENT) 

CASE  (MODE) 

WHEN  (FIRST-STEP) 

IF  TIME  OF  NEXT  STEP  <  TIME  OF  FINAL  EVENT,  THEN 
BUILD  EVENT  FOR  FIRST  STEP 
PUT  INTO  EVENTJ)  (EVENT-DATA) 

END  IF 

WHEN  (PARTIAL  I  STEP  1  LAST-STEP  !  INSTANT) 


get  transmitter  etate_vector  from  real-world 
gat  Intended  packet  from  info.packet 
get  damage  parameters  from  state-vector 
calculate  transmitter  transfer  function  (damage) 
transmitted  packet  ■  intended  .packet  *  transmitter  transfer 

function 

put  transmitted.packet  into  info.packets 

IF  MODE  *  STEP  k  calculation  will  continue  k 
TIME  OF  NEXT  STEP  <  TIME  OF  FINAL  EVENT,  THEN 
BUILD  EVENT  FOR  NEXT  STEP  (EVENT-DATA) 

PUT  INTO  EVENT-0  (EVENT-DATA) 

END  IF 

OTHERWISE 

ERROR 

END  CASE 
END  /*TTF*/ 


CPF  -  CALCULATE  PATH  FUNCTION 
4.3.3 


FUNCTION  -  THIS  MODULE  COMPUTES  THE  TRANSFORM  FOR  THE 
COMMUNICATION  PATH. 
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INPUT 

EVENT  -  THE  EVENT  D!  IV I  NO  THIS  1CTIVITT 

OUTPUT 

NONE 


CPF  (EVENT) 


get  connectivity  matrices  [old]  k  [now] 
gat  transmitter  state-vector  from  real .world 
if  this  ie  a  receive  event,  then 
do  for  each  sector  in  [new] 
search  sector  for  sonrees 
write  sources  in  [new] 
end  do 
end  if 

/*4 .3. 3. 1  -  check  for  new  sources*/ 
call  ens  (event;  new -source,  flrst.transmlt) 
if  new  .source  =  true,  then 

if  f irst.transnit  ■  true,  then 

/*4 .3.3.2  -  determine  transmitter  characteristics*/ 
call  dtc  (event,  state.vector ,  trans .characteristics) 
/*4.3.3.3  -  look  for  Intended  receivers*/ 
call  lfir  (event,  trans.characteristlcs,  state.vector) 
end  if 

if  this  is  a  transmit  event,  then 
do  for  each  sector  in  [old] 
search  eector  for  sources 
write  sources  in  [old] 
end  do 


/*4 .3.3.4  - 
call  ert  (event, 

else 

/*4. 3. 3.6  - 
call  ptf  (event, 
end  if 
end  if 


calculate  reception  times*/ 
state.vector) 

path  transfer  function*/ 
state.vector) 


END  /*CPF*/ 


APF  -  APPLY  PATH  FUNCTION 


4.3.4 


FUNCTION 

THIS  MODULE  DOES  THE  ACTUAL  CONVOLUTION  OF  THE 
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PATH  TRANSFER  FUICIIOI  WITH  THE  THAI  SMI  TTED  JACKET 
TO  GIVE  THE  INCIDENT  JACKET . 

IHFOT 

EVEBT  -  THE  EVENT  DRIVING  THIS  ACTIVITT 
OUTPUT 

INCIDENT -PACKET  -  THE  PACKET  ACTQALLT  DELIVERED  BT  THE 
COWUIICATIOI  PATH 


AP  F  (EVENT,  INCIDENT  JACKET) 

fat  tr  unit  tad -packet  froa  info  .packets 

gat  path  transfer  fnnetien  froa  path -fan  ctl  one 

Incident  .packet  ■  t  ran  salt  ted  -packet  *  path  transfer  function 

END  /*APF*/ 


RTF  -  RECEIVER  TRANSFER  FUNCTION 
4.3.6 


FUNCTION  -  THIS  MODULE  USES  THE  RECEIVER  STATE.  VECTOR 
INCLUDING  DAMAGE  PARAMETERS  TO  TRANSFORM  THE 
INCIDENT  JACKET  TO  THE  RECEIVED  JACKET 

INPUT 

EVEBT  -  THE  EVEBT  DRIVING  THIS  ACTIVITT 

INCIDENT  JACKET  -  THE  PACKET  RECEIVED  AT  THE  RECEIVER 

OUTPUT 

NONE 


RTF  (EVENT.  INCIDENT  JACKET) 

CASE  (MODE) 

WHEN  (FIRST  .STEP) 

IF  TIME  OF  NEXT  STEP  <  TIME  OF  FINAL  EVENT,  THEN 
BUILD  EVENT  FOR  FIRST  STEP 
PUT  INTO  EVEBT-Q  (EVENT-DATA) 

END  IF 

WHEN  (PARTIAL  I  STEP  1  LAST-STEP  I  INSTANT) 


get  receiver  state-vector  froa  real  world 

get  daaage  froa  at  ate.  vector 

calculate  receiver  transfer  fanetlon  (daaage) 
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re  calved  .packet  ■  1  acid  ant  .packat  * 

racalvar  traaafar  Inaction 
add  received  .packet  to  iafo  .packets 
bn lid  avast  to  a and  ratal vad .packat 
to  aaxt  destination  (ovaat.data) 
pnt  into  event _q  (event .data) 

IF  MODE  »  STEP  6  calculation  will  cost inn a  6 
TIME  OF  NEXT  8TEP  <  TIME  OF  FIVAL  EVEHT.  THE1 
BUILD  EVEHT  FOE  IEXT  STEP  (EVEHT .DATA) 

PUT  IHTO  EVEHT -0  (EVEHT .DATA) 

END  IF 

OTHERWISE 

ERROR 

END  CASE 

END  /*RTF*/ 


CHS  -  CHECK  FOR  HE*  SOURCES 
4.3.3. 1 


FUNCTION  -  THIS  MODULE  DETERMINES  IF  SOME  HE*  SOURCE 
HAS  BECOME  ACTIVE  THAT  MIGHT  AFFECT  COMMUIICATIOH3. 

INPUT 

EVENT  -  THE  EVEHT  DRIVING  THIS  ACTIVITY 
OUTPUT 

NEV.SOURCE  -  LOGICAL  VARIABLE  DENOTING  THE  PRESENCE 
OF  NEW  INTERFERENCE  SOURCES 

FIRST-TRAHSMIT  -  LOGICAL  VARIABLE  DEHOZING  FIRST  TRANSMISSION 

DEFINITIONS: 

[...]  DENOTES  A  MATRIK 

II  [...II |  DENOTES  THE  HORN  OF  A  MATRIX 


CHS  (EVEHT;  BEV  .SOURCE,  FIRST  .TRANSMIT) 

check  connectivity  sabaatrix  [new]  for  eaptlneee 
If  eapty,  then 
new.eonrce  m  true 
firat.tranaalt  -  true 

alee 
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if  1 1  [eld]  '[in]  1 1  >  0  ,  than 
nav-aoorca  ■  trot 
flag  active  eonreaa  la  [saw] 
flag  actlva  a act or a  la  {new] 

alaa 

nev.aonrce  •  falaa 
and  If 

firat.traaaalt  ■  falaa 
aad  if 

END  / *CNS*/ 


DTC  -  DETERMINE  TRANSMITTER  CHARACTERISTICS 
4. 3. 3. 2 


FUNCTION  -  THIS  MODULE  DETERMINES  THE  CHARACTERISTICS 
FOR  SOME  PARTICULAR  COMMUNICATION  TRANSMITTER 

INPUT 

EVENT  -  THE  EVENT  DRIVING  THIS  ACTIVITY 
STATE  VECTOR  -  THE  TRANSMITTER  STATE.VECTOR 

OUIPUT 

TRANS-CHARACTERISTICS  -  CHARACTERISTICS  FOR  A  TRANSMITTER 


DTC  (EVENT.  STATE.VECTOR.  TUNS -CHARACTERISTICS) 
END  /*DTC */ 


LFIR  -  LOOK  FOR  INTENDS)  RECEIVERS 
4. 3. 3. 3 


FUNCTION  -  THIS  MODULE  ADDS  TO  THE  CONNECTIVITY  MATRIX 
THAT  DEFINES  THE  PATHS  AND  RECEIVERS  FOR  A  PARTICULAR 
TRANSMITTER.  -OLD*  AND  "DEW"  VERSIONS  OF  THE  MATRIX  ARE 
WRITTEN  TO  A  FILE.  BOTH  "OLD*  AND  "NEW*  MATRICES  MUST 
BE  INITIALIZED  AT  THE  BEGINNING  OF  THE  SIMULATION. 

DEFINITIONS  - 

tbnd  “  trananlttar  frequency  band 
rbnd  “  racaivar  frequency  band 
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INPUT 

EVENT  -  THE  EVE9T  DRIVING  IBIS  ACT IV ITT 

TRANS  -CHARACTER 1ST ICS  -  CHARACTERISTICS  FOR  TRANSMITTER 

STATE. VECTOR  -  THE  TRANSMITTER  STATE.  VECTOR 

OUTPUT 

NONE 


LFIR  (EVENT.  TRANS. CHARACTERISTICS.  STATS.VECT01) 
get  trua.iv  froa  real.vorld 

part*  tranoav  for  frequency  chariot  or  loti  ea  (traaa.av;  tbnd) 
gat  intandad  racalvar  liat  froa  avant.daac 
do  for  all  Intandad  racalvara 
(at  rac.av  froa  raal.*orld 

paraa  rac.av  for  frequency  characteriatico  (rac.av;  rbnd) 

If  tbnd  irlthin  rbnd,  than 
aat  path  ■  no 

chack  tranarac  pair  for  loa  (trana jv,  rac.av) 

If  loa  s  yaa ,  than 

vrlta  racalvar -id  In  connectivity  aatrlcaa  [old]  8  [now] 
find  aactora  along  lea 

write  aactora  in  eonnactivity  aatrlcaa  [old]  8  [new] 
aat  path  ■  direct 

write  path  in  eonnactivity  aatrlcaa  [old]  8  [new] 
and  if 

chock  for  additional  patha  /* do  vavagnldoa  exiet?*/ 
do  for  each  al tarn at a  path 

write  rocelver-ID  in  connectivity  aatrlcaa  [old]  8  [now] 
find  aactora  along  alternate  path 

write  aactora  in  eonnactivity  aatrlcaa  [old]  8  [now] 
aat  path  “  indirect 

vrlta  path  in  connectivity  aatrlcaa  [old]  8  [now] 
and  do 

if  path  ■  no.  than 
write  "no  path"  aaaaago 
and  if 

aloe 

write  "  ineligible  receiver"  aoaaaga 

and  if 
and  do 

END  /*LFIR*/ 


CRT  -  CALCULATE  RECEPTION  TIMES 
4.3.3. 4 
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FURCTIOR  -  THIS  NODULE  CILCUUTES  1  IECEPTIOI  TIME 
FOR  EACH  RECEIVER. IDENTIFIED  8T  THE 
CQRRECTIVITT -MATRIX .  EVERTS  ARE  BUILT  AHD  PUT  IKTO 
THE  EVERT .1}  TO  SIMULATE  THE  RECEPTIOI  OF  THE  MESSAGES. 

INPUT 

EVERT  -  THE  EVERT  DRIVIRG  THIS  ACTIVITY 
STATE-VECTOR  -  THE  TRANSMITTER  STATE.  VECTOR 

OUTPUT 

RORE 


CRT  (EVERT.  STATB.VECTOR) 
ttrn  «  tima  from  avant  Rata 

gat  transmit  tar  jv  and  faography  Iron  raal. world 
C«t  conn matrix 

do  for  oach  ratal var  la  conn activity  matrix 
gat  racalvar.av  from  raal .world 
do  for  aach  path 

ca leu lata  vacuum  tranalt  tima 
build  avant  to  alanlata  racaptlon  (avant.data) 
put  Into  avant .q  (avant.data) 
and  do 
and  do 


ERD  /*CRT*/ 


PTF  -  PATH  TRANSFER  FURCTIOR 
4. 3. 3. 6 


FURCTIOR  -  THIS  NODULE  COMPUTES  THE  TRANSFORM  FOR  THE 
COMMUNICATION  PATH. 

INPUT 

EVERT  -  THE  EVERT  DRIVIRG  THIS  ACTIVITT 
STATE. VECIOR  -  THE  TRAHSMIITER  STATE.  VECTOR 

OUTPUT 

RONE 
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PTF  (EVEIT,  STATE-VECTOR) 

(it  path  lengths  and  diraetloaa  froa  conaactivlty-aatrix  [aav] 
calculate  hard  link  paraaatara 

calculate  soft  link  paraaetera  /*prinary  and  secondary  patha, 

over  or  la  land  and  water 
or  Ice*/ 

get  weather  aonrcea  froa  [new] 

calculate  weather  perturbations  /*solar  and  terrestrial*/ 

gat  nuclear  effects  sonrees  froa  connectivity-aatrix  [new] 

calculate  unclear  effects  perturbations 

calculate  path  transfer  function 

put  path  transfer  function  Into  path-functions 

END  /*PTF*/ 
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REAL-WORLD 


4.4  WEAPONS 
Level  2  Data  Flow 
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4.4.1  WEAPONS  CONTROLLER 

There  is  a  weapon’s  module  or  process  for  each  type  of  weapon.  The  controller  does  the  standard 
functions  of  getting  data  from  the  REAL-WORLD,  getting  and  building  EVENTS,  and  determining  which 
weapon  modules  to  call. 

4.4.2  CALCULATE  WEAPON  OPERATION 

This  series  of  modules  uses  the  EVENT-DATA  to  calculate  ATTACK -PARAMETERS  that  completely 
and  parametrically  describe  the  operation  of  the  weapon.  They  may  also  identify  future  weapon  operation 
that  must  be  calculated. 

4.4.3  CONSTRUCT  EVENTS 

This  module  constructs  EVENTs  using  ATTACK -PARAMETERS.  The  events  are  used  to  call  Event 
Physics  immediately  or  to  recall  the  required  weapon’s  module. 
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WEAPONS  -  SIMULATE  WEAPONS 
4.4.1 


FUNCTION 

THE  WEAPON'S  MODULE  CALCULATES  THE  ACTUAL  FUHCTIOI 
FOE  A  WEAPON  SUCH  AS  YIELD  FOR  A  BOMB 
OR  BEAM  DURATION  AND  INTENSITY  FOR  A  LASER. 

INPUT 

EVENT  DESC  -  THE  EVENT  DRIVING  THIS  ACTIVITY 

OUTPUT 

NONE 


WEAPONS  (EVENT .DESC) 

gat  avaat  froa  avaat  q  (avantdaac,  avant .data) 

CASE  (MODE) 

WHEN  (FIRST -STEP) 

IF  TIME  OF  NEXT  STEP  <  TIME  OF  FINAL  EVENT,  THEN 
BUILD  EVENT  FOR  FIRST  STEP 
PUT  INTO  EVEHT-Q  (EVENT  DATA) 

END  IF 

WHEN  (PARTIAL  I  STEP  I  LAST-STEP  I  INSTANT) 

gat  atata-vaetor  for  this  waapoa  froa  raal-vorld 
gat  this  waapoa* a  eavlroaaont  froa  raal .world 
/*4.4.2*/ 

calcnlata  operation  for  thla  waapoa  (otats.vactor, 

avant -data,  aaviroaaant, 
at  tack.par  aaat  ar  a) 


/•4.4.3  -  contract  avast  a*/ 

If  waapoa  amt  faactloa  at  a  latar  tlaa 

build  avant  to  coatiaaa  faactloa  (attack-paraaatars, 

avaat -data) 

add  to  avantjq  (avant  data) 
and  If 

balld  avaat  to  axacata  avaat  physics  laaadlatsly  (avsat  .data) 
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47  add  to  event .q  (« van t .data) 

48  /*o&4  4.4.3*/ 

49 

60  17  MODE  *  STEP  8  calculation  la  to  eontlana  8 

61  TIME  07  IE1T  STEP  <  TIKE  07  FIIiL  EVEJT,  THEN 

63  BUILD  EVEHT  FOR  IEXT  STEP  (EVENT -DATA) 

PUT  INTO  EVENT -Q  (EVENT-DATA) 

END  IF 

OTHERVISE 
ERROR 
END  CASE 

END  /*VEAPONS*/ 
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4.5  PHYSICS 
Level  2  Data  Flow 


REAL-WORLD 
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4.5  EVENT  PHYSICS 

4.5.1  EVENT  PHYSICS  CONTROLLER 

This  module  uses  the  EVENT J5ESC  given  to  it  by  the  Executive  to  get  the  appropriate  EVENT J)ATA. 
It  then  uses  information  extracted  from  the  EVENT-DATA  to  call  the  appropriate  module  to  perform  the 
event. 

4.5.2  DELETE  SV 

This  module  extracts  a  SVJD  from  the  EVENT-DATA  and  deletes  the  STATE-VECTOR  with  this  ID 
from  the  REAL-WORLD  file. 

4.5.3. U  GENERATE  OBJECT 

This  is  a  series  of  modules,  each  of  which  uses  parameters  from  EVENT -DATA  to  create  a  complete 
parameter  set  for  a  new  object.  It  converts  this  parameter  set  into  STATE-VECTOR  format  and  stores  the 
STATE-VECTOR  in  the  REAL-WORLD  file. 

4.5. 4. n  INTERACTION  CALCULATOR 

This  is  a  series  of  modules,  each  of  which  calculates  a  type  of  force-on-asset  interaction.  Each  module 
is  conceptually  of  the  “leroth-order  convolution"  optionally  followed  by  “interaction  loops”  that  refine  the 
eeroth-order  calculations. 

4.5. 5. n  INTERACTION  DELIMITER 

This  is  a  set  of  modules,  each  of  which  accomplishes  the  following  for  a  particular  effect  type: 

1)  identifies  affected  assets 

2)  creates  EVENTs  to  trigger  the  interaction  calculations. 

In  the  process  of  identifying  the  affected  assets,  it  may  update  object  positions  and/or  conditions  beyond 
the  last  Mother  Nature  call,  but  these  updates  will  not  be  stored  in  the  REAL-WORLD  file. 
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EP  -  EVERT  PHYSICS 

4.6.1 


rUKCTIOI 

THIS  MODULE  GETS  THE  EVERT  IRFORMATIOR  ARD  THER  SELECTS 
THE  MODULE  REQUIRED  TO  EXECUTE  THE  EVERT. 

IHPUT 

EVEHT-DESC  -  POIITER  TO  THE  EVERT  DRIVIRQ  THIS  ACTIVITY 

OUTPUT 

ROHE 


EP  (EVEHT-DESC) 

get  avail  t  from  avant-q  (event -dose,  avast -data) 
axtract  ap.typa  froa  avast -data 
caaa  (ap.typa) 
whan  (delate. av) 

/*4.6.3  -  dalata  atata  vector*/ 
call  da  lav  (avast -data) 
abas  (geserate.object) 

axtract  object .type  frea  avast -data 
caaa  objact.typa 
vhas  (objact.typa  s) 

/*4.6.3.n  -  generate  objact*/ 
call  gasobj  (avast.data) 


asd  caaa 

abas  ( 1st ar actios) 

axtract  lstaractios.typa  froa  avast.data 
caaa  (1  star  act  iea.typa) 
vhas  (lstaractios-typa  s) 

/*4.6.4.s  -  lstaractios  calculator*/ 
call  lscalul  (avast) 


and  caaa 

abas  (intaractioB-dallaitar) 
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48 

48 

50 
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60 

70 

71 
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73 
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76 

77 

78 
78 
80 
81 
82 

83 

84 
86 
86 

87 

88 
80 
80 
81 
02 
83 
04 
06 
86 


extract  int  erect  lon.dellaiter -type  frea  avast  .data 
case  (later act ion.de Halter  .type) 

•has  (interact  ion-dallalter-type  a) 

/*4.6.6.n  -  lBtaractloa  delimiter*/ 
call  ladalla  (event-data) 


end  caaa 
and  case 

END  /*EP*/ 


DELSV  -  DELETE  STATE  VECTOR 
4.6.2 


function 

THIS  MODULE  FINDS  THE  IDENTIFICATION  AND 
LOCATION  OF  THE  STATE-VECTOR  AND  DELETES  IT  FROM 
THE  REAL-VORLD. 

INPUT 

EVENT-DATA  -  THE  EVENT  DEFINING  THE  STATE  VECTOR  TO  DELETE 

OUTPUT 

NONE 


DELSV  (EVENTJJATA) 

extract  ev.id  from  event -data 

find  state  .vector  In  real-world  (ev.ld) 

delete  etate.vector  froa  real.vorld  (ev.ld) 

END  /*DELSV*/ 


GENOBJ  -  GENERATE  OBJECT 
4.6.3.B 


FUNCTION 

THIS  MODULE  USES  THE  PARAMETERS  FROM  EVENT-DATA  TO 
CREATE  THE  PARAMETER  SET  FOR  A  NEWLY  CREATED  OBJECT. 
THESE  PARAMETERS  ARE  STORED  IN  STATE. VECTOR  FORMAT 
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IV  REAL-WORLD. 

input 

EVENT-DATA  -  THE  EVEVT  CAUSIVO  THE  OBJECT  TO  BE  CREATED 

OUTPUT 

VOVE 


GENOBJ  (EVENT  DATA) 

ganarata  object 
construct  statavactor 
pat  stata. victor  into  rial  .world 
if  objact  raqnlrss  aothar  aatara  apdata,  than 
build  avant  to  ran  aothar  natara  (avantdata) 
pat  into  avant-q  (avant  data) 
and  if 

END  /♦GENOBJ*/ 


INCALUL  -  INTERACTION  CALCULATOR 
4. 6. 4. a 


FUNCTION 

THIS  MODULE  CALCULATES  A  TYPE  OF  FORCE  ON  ASSET 
INTERACTION.  CONCEPTUALLY  THIS  IS  A  ZEROTH -ORDER 
CONVOLUTION  OPTIONALLY  FOLLOWED  BY  INTERACTION 
LOOPS  THAT  REFINE  THE  ZEROTH. ORDER  CALCULATION. 

INPUT 

EVENT  -  THE  EVENT  DEFINING  THE  CALCULATION 

OUTPUT 

NONE 


INCALCU  (EVENT) 

CASE  (MODE) 

WHEN  (FIRST  STEP) 

IF  TIME  OF  NEXT  STEP  <  TIME  OF  FINAL  EVENT,  THEN 
CALCULATE  TIME  OF  FIRST  STEP 
BUILD  EVENT  FOR  FIRST  STEP 
PUT  INTO  EVENT J)  (EVENT-DATA) 

END  IF 
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LEVEL  2  &  3  EVENT  PHYSICS 


WHEN  (PARTIAL  !  STEP  !  LA  ST -STEP  V  INSTANT) 

gat  atata -victors,  geography,  environment  from  rail  world 
update  fait  atate_vector< .  fait  environment  component* 
do  sarotli  order  convolution 
do  interaction  loope  to  raf ina  i troth  ordar 
modify  atatt-vactor  to  reflect  naw  damage  parameters 
raplaca  atata.vactor  in  raal-world  with  aodifiad  etata_veetor 
If  interaction  calculation  apawnad  naw  objects 
do  for  tnch  now  objact 

construct  event-data  to  do  ganaratlon 
/*4.6.3  -  ganarata  objact*/ 
call  ganobj  (event-data) 
and  do 
and  if 

if  intaractlon  calculation  required  dalation  of  objaeta 
do  for  aach  objact  to  ba  dalatad 
conatrnct  avant-data  for  dalation 

/*4,5.2  *  dalata  atata  victor*/ 
call  delev  (avant-data) 
and  do 
and  If 

IF  MODE  *  STEP  8  calculation  will  continue  8 
TIME  OF  REIT  STEP  <  TIME  OF  FINAL  EVENT,  THEN 
CALCULATE  TIME  OF  REIT  STEP 
BUILD  EVERT  FOR  REIT  STEP  (EVENT-DATA) 

PUT  INTO  EVEKMJ  (EVENT J)ATA) 

END  IF 

OTHERWISE 

ERROR 

END  CASE 

END  /*INCALCU*/ 


INDELIM  -  INTERACTION  DELIMITER 
46. 6. n 


FUNCTION 

FOR  A  PARTICULAR  EFFECT  TYPE,  THIS  MODULE  IDENTIFIES 
AFFECTED  ASSETS  AND  CREATES  EVENTS  TO  TRIGGER  THE 
INTERACTION  CALCULATIONS,  THE  IDENTIFICATION  PROCESS 
MAT  REQUIRE  THAT  OBJECT  POSITIONS  OR 
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206 

207 

206 
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210 

211 

212 

213 

214 

216 

216 

217 

216 

219 


LEVEL  2  &  3  EVENT  PHYSICS 


COHDIIQNS  BE  UPDATED  BETOHD  THE  POUT  OF  THE  LAST  MOTHER 
NATURE  CALL.  THESE  UPDATES  HOWEVER  ARE  WOT  SAVED  II 
THE  REAL-WORLD. 

INPUT 

EVENT-DATA  -  THE  DATA  DEFINING  THE  INTERACTOV 

OUTPUT 

NONE 


INDELIM  (EVENT  J)ATA) 

git  state, vacton ,  geography,  environment  from  rial-vorld 
update  fait  s  tat  • -vectors,  fait  environment  components 
do  for  iach  etate-veetor  in  question 
decide  if  It  will  Intiract 
If  it  vlll  intiract 

find  out  whin  it  will  intiract 
construct  ivint  to  do  thi  lntiraction 
put  ivint  In  thi  ivent.q 
end  If 
end  do 

END  /*INDELIM*/ 
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NAME:  ATTACK  .PARAMETERS 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW I  FILE 

DESCRIPTION  This  Is  information  doacribing  how  m  wompom  fnnctlono  (o.g. 
ylold,  duration)  for  inclusion  ia  EVES T -DATA. 

COMPOS ITI 01: 

ORGANIZATION  (  if  filo  ): 

MOTES: 


HAME:  ATTACK-PLAN 
ALIASES: 

TYPE:  DATA  ELENEHT  |  DATA  FLO* I  FILE 

DESCRIPTION  Offoaaiva  plana  for  tha  battla  aaaagara. 

COMPOSITIOI: 

ORGANIZATIOH  (  if  film  ): 

NOTES: 


NAME:  BATTLE -MGR -DIRECTIVE 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW I  FILE 

DESCRIPTION  A  racordad  ordar  aant  by  m  battla  aanagar  to  aoma  davica 
andar  ita  control. 

COMPOSITIOI:  EVENT 

ORGANIZATION  (  if  film  ): 

NOTES: 


NAME:  CMD -ATTACK-PLAN 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW I  FILE 

DATA  DEFINITIONS 
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DESCRIPTION:  Th#  naar  command*  to  apacify  tha  attack  plan. 
C0MP0SITI0H : 

ORGANIZATION  (  If  fil*  ): 

BOTES: 


SAME:  CMD  ENVIRONMENT 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW I  FILE 

DESCRIPTION:  Th**a  ara  th*  n**r  command*  to  apacify  tha  aavironmaat  for 
tha  aimnlation. 

COMPOSITION : 

ORGANIZATION  (  if  fil*  ): 

BOTES: 


NAME:  CMD. GEOGRAPHY 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW I  FILE 

DESCRIPTION:  Thaaa  ar*  th#  naar  command*  to  apacify  tha  gaography. 
COMPOSITION: 

ORGANIZATION  (  if  fil*  ): 

NOTES: 


NAME:  CMD. INTERVENTIONS 
ALIASES: 

TYPE:  DATA  ELEMEHT  I  DATA  FLOW I  FILE 

DESCRIPTION:  Thaaa  ara  tha  naar  command*  to  apacify  avanta  or  actioma  that 
intarrnpt,  changa,  ovarrida,  or  raport  on  activitlaa. 

COMPOSITION: 
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ORGAHIZATIOV  (  if  flit  ): 

VOTES: 


SAME:  CMD -MODULES 
ALIASES: 

TYPE:  DATA  ELEMEHT  |  DATA  FLOW I  FILE 

DESCRIPT I OH:  Thaaa  ara  tha  uaar  command*  uaad  to  aalact  til*  particular 

coda  Bodulaa  to  ba  uaad  for  tha  a isolation.  Tha  coda  aodulaa 
aalactad  will  dafina  tha  fidality  of  tha  alaulatioa. 

COMPOSITION: 

ORCAHIZATIOH  (  if  fila  ): 

VOTES: 


VAME:  CMD.ORDER.OF -BATTLE 
ALIASES: 

ITPE:  DATA  ELEMENT  |  DATA  FLOW I  FILE 

DESCRIPTIOV:  Tha  uaar  coaaaada  to  apacify  tha  initial  ordar  of  battla 
including  aquipnant  and  forcaa. 

COMPOS I TI OH: 

ORCAHIZATIOH  (  If  fila  ): 

VOTES: 


HAME:  CMD  OUTPUT -SPECS 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW I  FILE 

DESCRIPTION:  Thaaa  ara  tha  uaar  coananda  uaad  to  dafina  tha  output  that 
tha  aiaulatioa  la  to  collact  and  praaant . 

COMPOS ITIOH: 

OkCAVIZATIOV  (  if  fila  ): 
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ROTES: 


RIME:  CMD  PLANNED  RESPONSES 
ALIASES: 

ITPE:  DATA  ELEMENT  |  DATA  FLOW I  FILE 

DESCRIPTION:  Thaaa  it*  tha  aaar  coananda  that  opacify  and  aalact  tha 
dafanaiva  plana  for  tha  battla  aanagar. 

COMPOSITION: 

ORGANIZATION  (  if  flla  ): 

NOTES: 


NAME:  CMD  .PROMPT 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW I  FILE 

DESCRIPTION;  Thaaa  ora  tha  proapta  that  aaaiat  tha  aaar  la  deciding  vhat 
to  do  nnxt. 

COMPOSITION: 

ORGANIZATION  (  if  flla  ): 

NOTES: 


NAME:  CMDS 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW  I  FILE 

DESCRIPTION:  Thaaa  ara  tha  coaaaada  that  allow  tha  aaar  to  aetnp,  ran,  and 
obaarva  tha  coda  and  aiaalation. 

COMPOSITION: 

{ CMD .ORDER -OF  .BATTLE  /*  tha  initial  ordar  of 
battla  -  thla  incladaa  equipment  and  forcaa  */ 

♦  CMD  .ATTACK -PLAN  ♦  CMD  JPLANRED -RESPONSES} 

+  {CMD .INTERVENTION}  /*  avanta  to  trigger  natural 
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ud  aan-iapoaed  actions  */ 

«  CMS -MODULES  ♦  CMD.GEOCRAPHT  ♦  CMS  -ENVIRONMENT 
♦  CMS -OUTPUT  -SPECS 

ORGANIZATION  (It  tils) : 

MOTES:  Modal  fidelity  is  dataninad  by  the  salactioa  of  aodnlas  for  the 
simulation.  For  aost  casas  fidallty  will  be  nixed. 


SAME:  CODE-DATA 
ALIASES: 

TTPE:  DATA  ELEMEIT  I  DATA  FLOW  |  FILE 

DESCRIPTION:  This  la  inforaation  that  daflnaa  tha  atata  or  atatna  of  tha 
aianlatlon  program. 

COMPOSITION :  binary  rapraaantatlon  of  coda  ayataa  atatna  aa  to  written  tha 
POST-PROCESSING  and  RESTAITJUMPS  filaa. 

ORGANIZATION  (If  f ila) : 

NOTES:  Tha  CODE-DATA  definition  appliaa  to  binary  aachins  representation 
of  data  that  tha  user  has  requested. 


NAME:  CODE-STATUS 
ALIASES: 

TTPE:  DATA  ELEMENT  I  DATA  FLOW  I  FILE 

DESCRIPTION:  This  la  tha  atatna  or  atata  of  tha  actnal  aianlatlon  prograa 
-not  tha  aianlatlon  -aa  displayed  for  tha  near. 

COMPOSITION:  Text  rapraaantatlon  of  tha  CODE-DATA  data  definition. 

ORGANIZATION  (if  file) : 

NOTES:  The  CODE-STATUS  definition  appliaa  to  text  rapraaantatlon  of  data 
that  tha  nsar  has  request ad. 


NAME:  CONFLICT 
ALIASES: 

TTPE:  DATA  ELEMENT  I  DATA  FLOW  I  FILE 
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DESCRIPTION:  Thia  ia  a  flag  that  daflaaa  whether  a  conflict  exists  or  mot. 

COMPOSITION:  TRUE  |  FALSE 

TRUE  -  a  conflict  oxlata 
FALSE  -  no  conflict 

ORGANIZATION  (if  file): 

NOTES: 


NAME:  CONFLICT-LIST 
ALIASES: 

ITPE:  DATA  ELEMENT  I  DATA  FLOW I  FILE 

DESCRIPTION;  Thin  ia  a  Hat  of  ontrloa  froa  tha  IN -PROCESS  filo  that  aro 
in  conflict  with  ono  of  tho  aaaota  from  a  parti color  ovont. 

COMPOSITION:  {SV.ID  ♦  FINAL-EVENT -PIR} 

ORGANIZATION  (if  filo) : 

NOTES: 


NAME:  CONNECTIVITY  JUTRIX 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW  |  FILE 

DESCRIPTION:  Thin  matrix  vhlch  actually  la  two  aubaatrices  contalna  tho 
poaaiblo  common icat ion  paths  and  racolvora  for  a  packat 
tranaalaBioa  froa  a  particular  tranaaittor.  Tho  noat  general 
(high* fidelity)  fora  of  tho  aatrix  ia  flve-dlaenslonal, 
with  lndlcoa  (I.J.K.L.M). 

I  ldantlfiaa  tho  tranaaittar, 

J  identifies  tho  rocoivor(a), 

K  idontlfloa  tho  tranaalaoion  path (a), 

L  ldontifloo  tho  aactor(a)  that  contain  tho  K-th  path,  and 
M  idontlfloa  tho  conaonl cat ions  intorforonco  aourcos. 
COMPOSITION:  old  *  now 
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nav  -  eubaatrix  for  now  tranaalaaiona 
old  -  oubnatrix  for  axlatiag  tranaalaalona. 

ORGAIIZATIOI  (if  fllo): 

ROTES: 


HANE:  CONST AITS 
ALIASES: 

ITPE:  DATA  ELEMENT  |  DATA  FLOW  |  FILE 

DESCRIPTIOI:  Tho  standard  constants  oaod  throughout  tha  aiaulotion  program 
a.g.  pi,  tho  opood  of  light,  otc. 


COMPOSITIOI: 

ORGAIIZATIOI  (if  f ilo) : 

ROTES:  Conotauto  will  not  ba  hardcodod  into  tha  prograa.  They  will  ba 
dafinod  onca  la  thio  fila  and  loaded  into  tha  coda  at 
initialisation  tlaa. 


NAME:  DAMAGE 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW  |  FILE 

DESCRIPTIOI :Thia  apocifloa  tha  fraction  of  daaaga  to  an  aaaat. 
COMPOSITIOI: 

DEAD  -  1  ALIVE  -  0  ALIVE  <  DAMACE  <  DEAD 
ORGAIIZATIOI:  (if  fila): 

NOTES: 


NAME:  DATE-TIME 
ALIASES: 

TTPE:  DATA  ELEMENT  I  DATA  FLOW  I  FILE 

DESCRIPTION:  Thia  ia  tha  ataadard  format  for  text  data  and  tlaa. 
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COMPOSITIOI: 

ORGANIZATION  (If  f lit) : 

NOTES:  ¥•  may  wish  to  hava  this  information  in  many  diffarant  format* . 


NAME:  DESTINATION 
ALIASES: 

TTPE:  DATA  ELEMENT  I  DATA  FLOW  |  FILE 

DESCRIPTION:  Thia  idantifia*  tha  nodal*  to  ba  axacntad. 
COMPOSITION: 

ORGANIZATION  (if  f ila) : 

NOTES: 


NAME:  DISPLAYS 
ALIASES: 

TYPE:  Dili  ELEME1T  |  PITA  FLOW I  FILE 

DESCRIPTION:  Theae  are  tha  terminal  diaplaye  for  tha  near  of  tha  alanlatioa. 
COMPOSITIOI: 

[MENU  |  CMD  PROMPT]  /*  prompting  via  aaaua  or  taxt  */ 

♦  CODE  STATUS  /*  atataa  of  tha  alanlatioa  program  */ 

*  SIM  STATUS  /*  atatna  of  tha  aiaalatad  battla-aapa, 
bar  charta,  trajactorlaa.atc.  */ 

ORGANIZATION  (if  f ila) : 

NOTES: 


NAME:  DO -EVENT 
ALIASES: 

TTPE:  DATA  ELEMENT  I  DATA  FLO*  |  FILE 

DESCRIPTION:  Thia  ia  a  flag  ratnraad  by  tha  conflict  handler  to  tha 

executive  controller  indicating  whether  tha  new  event  ahonld  ba 
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axe cut ad  or  not. 

COMPOSITION :  TRUE  |  FALSE 

TRUE  -  execute  avast 

FALSE  -  do  not  axacnta  tha  avant 

ORGANIZATION  (if  f ila) : 

NOTES: 


NAME:  DO  J70V 
ALIASES: 

TTPE:  DATA  ELEMENT!  DATA  FLOW  I  FILE 

DESCRIPTION :  This  in  a  fl>|  in  an  avant  that  indicataa  whether  an  avant  can 
ba  axscntad  nov  or  if  it  moat  go  to  tha  conflict  handlar  first. 

COMPOSITION:  TRUE  I  FALSE 

ORGANIZATION  (if  f ila) : 

NOTES:  TRUE  -  EVENT  can  ba  axscntad  vithont  going  to  conflict  handlar 
FALSE  -  EVENT  mnat  go  to  conflict  handlar. 


NAME:  ENVIRONMENT 
ALIASES: 

TTPE:  DATA  ELEMENT  I  DATA  FLOV  |  FILE 
DESCRIPTION:  Tha  physical  world’s  anvironnant. 
COMPOSITION:  waathar  ♦  apaca  +  ana*  *  ate 
ORGANIZATION  (if  fils): 

NOTES:  *  ana  la  daflnad  an  ElactroMagnatic  Envlronnant. 


NAME:  EP .TTPE 
ALIASES: 

TTPE:  DATA  ELEMENT  I  DATA  FLOV  |  FILE 
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DESCRIPTION  Part  of  EVENT  Dili,  this  parameter  deaotaa  which  of  several 
typaa  of  calcalatloaa  ia  to  bo  performed  by  EVERT  PHYSICS. 
It  may  legally  acquire  tha  following  valmes: 

DELETE -SV 
GENERA  TEOBJECI 
IHIE2ACTI0H-DELIMITATI0I 
ISTE&ACTIOH . 

CONPOSITIOH ; 

ORGANIZATION  (If  f lie) : 

NOTES: 


NAME:  ERROR _MSG 
ALIASES: 

TYPE:  DATA  ELEMENT  (  DATA  FLOW I  FILE 

DESCRIPTION:  Tha  atandard  format  text  aaaaago  pnt  ont  whoa  tha  eiaalatioa 
program  dot acta  an  error. 

COMPOSITION:  TEXT -MSG 

ORGANIZATION  (If  file): 

NOTES: 


NAME:  EV.DATA 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW I  FILE 

DESCRIPTION:  These  are  event  specific  data  that  are  part  of  the  EVENT -DATA 
definition.  Each  event  typo  will  aoat  likely  have  a  dlfforont 
format  for  this  struct are. 

COMPOSITION:  [PREV.TIME]  •*  event  dependent  data 

ORGANIZATION  (If  file) : 

NOTES: 
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NAME:  EVENT 
ALIASES: 

TIPS:  DATA  ELMEBIl  DATA  FLOW  t  FILE 

DESCBIPTIOI:  This  ia  as  activity  that  la  to  occar  at  aoaa  apaelflc  tima. 
COMPOSITION :  EVENT -DESC  ♦  EVENT  LATA 
ORGANIZATION  (if  fila): 

NOTES: 


NAME:  EVENT  J> AT A  (ganaric) 

ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW I  FILE 

DESCRIPTION:  Thla  la  tha  (gaaaric)  atruetnra  of  tha  data  part  of  tha  EVENT  q 
fila.  Each  avant  typa  will  Boat  likaly  hava  a  dlffarant 
EVJJATA  format. 

COMPOSITION: 

TIME  /*  whan  tha  avant  ia  to  taka  placa  */ 

♦  SOURCE  /•  who  originatad  tha  avant  */ 

♦  DESTINATION  /•  modulo  to  ba  axacatad  */ 

♦  EV  DATA  /*  avant  apaclfic  information  */ 

ORGANIZATION  (if  fila): 

NOTES: 


NAME:  EVENT-DATA-PTR 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW  |  FILE 

DESCRIPTION:  Thin  ia  tha  addraaa  of  EVENT  -DATA  in  tha  EVENT  .Q  fila. 
COMPOSITION: 

ORGANIZATION  (if  fila) : 

NOTES: 
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HAME:  EVENT -DESC 
ALIASES: 

TTPE:  DATA  ELEMENT  |  DATA  FLOW I  PILE 

DESCRIPTION:  This  la  tha  etructnra  of  tha  polntar  part  of  tha  EVENT. Q  flla. 
COMPOSITION: 


TIME  /*  whan  tha  avont  la  to  taka  placa*/ 

♦  EVENT -DATA  PTR  /*  polntar  to  tha  EVENT  .DATA  antry*/ 

♦  DESTINATION  /*  to  whoa  tha  avant  la  daatlsad  */ 

♦  {SV  ID}  /*  tha  aaaata  involvad  is  tha  avast*/ 

*  FINAL-EVENT  JPTR  /*  a  polntar  to  tha  EVENT  DESC  of  tha 
final  avant  of  an  axtandsd  avast*/ 

*  DO-NOW  /*  flag  Indicating  if  conflict  la 
already  dona  and  tha  avast  cas  ba 
axacntad  without  going  through  tha 
conflict  handlar*/ 

*  MODE  /*  tha  aoda  is  which  tha  avast  la  to 
bo  calcnlatad  •/ 

ORGANIZATION  (If  flla) : 

NOTES:  Tha  maxlnua  number  of  SVIDs  la  2  (two). 


NAME:  EVENT.Q 

ALIASES: 

TTPE:  DATA  ELEMENT  |  DATA  FLOV  I  FILE 

DESCRIPTION:  Thla  la  a  tina- order ad  aoriaa  of  avasta  uaad  to  triggar 
activltiaa  Is  tha  simulation. 

COMPOSITION:  EVENT 

ORGANIZATION  (if  flla): 

ORGANIZATION  (if  fila):  Tha  fila  conaiata  of  a  data  aactlon  is  arbitrary 
ordar  and  a  compact  tina-ordarad  list  pointing  to  antrioa  is 
tha  data  aactlon. 


NOTES: 
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NAME:  FIRST -TRANSMIT 
ALIASES 

TYPE:  DATA  ELEMENT  |  DATA  FLOW I  FILE 

DESCRIPTION:  Thia  la  a  logical  varlabla  denoting  flrat  communication 
t rental anion. 

COMPOSITION :  TRUE  |  FALSE 

ORGANIZATION:  (If  file): 

ROTES: 


NAME:  CEOG&APHT 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLO»  |  FILE 

DESCRIPTION:  Thla  la  a  aap  of  tho  world  daflnad  to  tha  extent  needed  for 
tho  simulation. 

COMPOSITION: 

ORGANIZATION  (If  flla) : 

NOTES: 


NAME:  GLOBAL-SIMULATION-DATA 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FL01  I  FILE 
DESCRIPTION: 

COMPOSITION: 

ORGANIZATION  (if  flla): 

NOTES:  la  thla  identical  or  ralatad  to  SIM-STATUS  or  SIM-DATA? 


NAME:  GRID-QUANTITY 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW I  FILE 
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DESCRIPTION  This  la  a  quantity  anch  aa  alactromagnatlc  anvlronaant  or 
nonlocal  waathar  that  ia  atorad  in  DETEC  in  a  diacratizad 
faahion,  tha  GRID  baing  tha  baaia  for  diacratisatloa. 


COMPOSITION : 
ORGANIZATION  (if  f ila) : 
NOTES: 


NAME:  INCIDENT-PACKET 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW!  FILE 

DESCRIPTION:  Thia  ia  tha  commnnicatioa  packat  that  arrlvad  at  tha  racaivar. 

It  ia  tha  TRANSMITTED -PACKET  aodlfiad  by  tha  path  tranafar 
fnnctlon.  For  a  porfact  coaannication  path,  it  ia  ldantical  to 
tha  TRANSMITTED -PACKET. 

COMPOSITION:  PACKET 

ORGANIZATION  (if  f ila) : 

NOTES: 


NAME:  INFO-DATA 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW I  FILE 

DESCRIPTION:  Thaao  nr a  tha  data  accompanying  an  information  packat.  Thara 
probably  will  ba  many  difiarant  format a  for  thaaa  data. 

COMPOSITION: 

ORGANIZATION  (if  f ila) : 

NOTES:  Thia  will  lnclnda  rontlng  information  if  nocaaaary. 


NAME:  INFO -PACKETS 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOV  |  FILE 

DESCRIPTION:  INFO -PACKETS  la  a  film  containing  aaaaagaa  that  ara  tranamlttad 
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from  aaaat  to  •.•■at . 

COMPOSITION :  {PICKET } 
ORGANIZATION  (if  f  Ila)  : 

NOTES: 


NAME:  INFOJ’TH 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW  |  FILE 

DESCRIPTION:  Thia  ia  tha  addraaa  of  INFO-DATA  that  la  part  of  a  packat, 
COMPOSITION: 

ORGANIZATION  (if  f ila) : 

NOTES: 


NAME:  IN-PROGRESS 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW  |  FILE 

DESCRIPTION:  Thia  ia  a  liat  of  aaaat  ldantlf icntiom  for  which  as  axtandad 
langth  a  initiation  ia  cnrrantly  baing  dona.  It  ia  poaaibla 
for  a  aingla  aaaat  to  ba  liatad  aavaral  tint*. 

COMPOSITION: 

(SV-ID  *  FINAL -EVEN  T-PTR}  /*  location  of  final 
EVEHT-PTR  in  EVEHTJJ  for  an  axtandad  avant  •/ 

ORGANIZATION  (if  f ila) : 

NOTES: 


NAME:  INTENDED-PACKET 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW I  FILE 

DESCRIPTION:  Thia  la  tha  corract  communication  pack at  that  tho  aandar 
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intended  to  tranaalt. 
COMPOSITION  PACKET 
ORGANIZATION  (if  fils): 

VOTES: 


NAME:  INTERACTION -DELIMITER-TYPE 
ALIASES: 

ITPE:  DATA  ELEMENT  1  DATA  FLO*  |  FILE 

DESCRIPTION:  Part  of  EVENT-DATA,  this  paraaotar  indicator  which  typo  of 
off act  aa  iatoractloa  delimitation  ia  to  bo  parforaod. 

COMP OS IT I DI: 

ORGANIZATION  (If  f ila) : 

NOTES: 


NAME:  IN TER ACT I ON. TYPE 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOV  t  FILE 

DESCRIPTION:  Part  of  EVENT  .DATA,  thio  paraaotar  indleatoa  which  typo 
(affoct-oa-aaaat)  of  lataractioa  ia  to  ba  calculated. 

COMPOSITION: 

ORCANIZATION  (if  f ila) : 

NOTES: 


NAME:  INTERRUPT 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLO*  |  FILE 

DESCRIPTION:  Thla  la  a  control  flag,  returned  by  tha  executive  to  the 
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nan agar,  that  indicat*!  th*  raaion  th*  «x*cntiv*  it  stopping 
or  suspending. 

COMPOSITION :  INTERVENE  |  COMPLETE  |  FiTiL -ERROR  |  fiO  INTR 

INTERVENE  -  th*  user  ha*  r*qu*«t*d  an  int*rv*ntion  ao  that  a 
chang*  to  th*  eonrs*  of  th*  simulation  cam  b*  mad*. 

COMPLETE  -  th*  simulation  ha*  couplet *d. 

FATAL  liRROR  -  th*  executive  ha*  detected  an  *rror  and  cannot 
continue . 

NQ-INTR  -  No  Intarrnpt  haa  occurred. 

ORGANIZATION  (if  f 11*) : 

NOTES; 


NAME:  INTERVENTIONS 
ALIASES: 

TYPE:  DATA  ELEMENT  1  DATA  FLOW!  FILE 

DESCRIPTION:  Than*  art  «v*nti  or  action*  that  Intarrnpt,  change,  and 
override  SCENARIO  conditions  only, 

COMPOSITION: 

ORGANIZATION  (if  f 11*) : 

NOTES: 


NAME:  MENU 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW I  FILE 

DESCRIPTION:  Thin  la  th*  sat  of  selectable  option*  that  nr*  dlaplayad  for 
th*  user. 

COMPOSITION: 

ORGANIZATION  (if  fill): 

NOTES: 
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NAME:  MB  AGAIN 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOV  I  FILE 

DESCRIPTION:  This  Is  s  flag  indicating  whether  MOTHER -NATURE  aodnlas  ara 
to  ba  callad  again  to  contlnna  thalr  calculation . 

COMPOSITION:  TRUE  I  FALSE 

ORGANIZATION  (if  f 11a) : 

NOTES: 


NAME:  MN -EVENT-PARAMETERS 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOV  I  FILE 

DESCRIPTION:  This  is  a  fila  that  contains  paraaetere  describing  all  EVENT 
requests  froa  MOTHER JfATURE  submodules.  It  is  used  to 
construct  one  or  aora  EVENTS  to  exercise  soaa  or  all  of  the 
MOTHER  NATURE  snbaodnlas. 

COMPOSITION:  (SV.CLASS.ID  ♦  NEXT-TIME} 

ORGANIZATION  (if  fils): 

NOTES: 


NAME:  MN  GEOGRAPHY 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOV  |  FILE 

DESCRIPTION:  This  is  a  taaporary  fils  that  stores  the  GEOGRAPHY  iaforaatloa 
needed  by  the  Grid  Quantity  Calculation  aodnlas. 

COMPOSITION: 

ORGANIZATION  (if  file): 
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NOTES: 


NAME:  MN -GEOGRAPHY  REQUEST 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW I  FILE 

DESCRIPTION:  Thia  ldantifiea  tha  typa  and  extant  of  GEOGRAPHY  information 
noodad  by  a  particular  GRID  QUANTITY  calculator,  all  dona  In 
MOTHER -NATURE. 

COMPOSITION: 

ORGANIZATION  (if  f ila) : 

NOTES: 


NAME:  MN -SOURCES 
ALIASES: 

TYPE:  DATA  ELEMENT  t  DATA  FLOW  I  FILE 

DESCRIPTION;  Thia  ia  a  temporary  fila  that  atorea  tha  aonrca  STATE. VECTORS 
noaded  by  tha  GRID-QUANTITY  calculation  aodnlaa. 

COMPOSITION: 

ORGANIZATION  (if  file) : 

NOTES: 


NAME:  MODE 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW  |  FILE 

DESCRIPTION:  Noda  definee  tha  particular  conflict  reaolution  in  which  a 
module  la  anppoaad  to  axacuta  in. 

COMPOSITION:  INSTANT  |  FIRST -STEP  I  STEP  I  LAST-STEP  |  PARTIAL 

INSTANT  -  axacuta  tha  lnatantanaoua  modulo 

FIRST-STEP  -  put  an  avant  in  tha  EVENT-Q  to  atart  tha  firat  atap 
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of  a  conflict  resolution.  1  step  event  ie  generated 
but  no  calculations  are  done. 

STEP  -  execute  the  nodule  froa  the  laat  tine  run  to  the  present 
tine  and  put  an  event  in  the  EVENT.Q  to  initiate  the 
next  step  of  the  conflict  resolution. 

LIST-STEP  -  complete  execution  of  the  extended  event  and  do  not 
put  a  step  event  in  the  queue. 

PARTIAL  -  execute  the  nodule  from  the  last  time  run  to  the 
present  tine.  No  etep  event  is  generated. 

ORGANIZATION  (if  file) : 

NOTES: 


NAME:  MODULE-LIBRARY 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOY  I  FILE 

DESCRIPTION:  These  are  the  various  versions  of  the  code  nodules  ae  maintained 

by  the  SOURCE  CODE  CONTROL  SYSTB4.  The  user  may  select  the  nodules 
appropriate  to  a  given  simulation. 

COMPOSITION: 

ORGANIZATION  (if  file) : 

NOTES: 


NAME:  MODULE-NAME 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW  |  FILE 

DESCRIPTION:  This  is  the  standard  format  text  module  name.  This  is  the 
FORTRAN  name. 

COMPOSITION: 

ORGANIZATION  (if  file) : 

NOTES: 
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SAME:  MSG  .CODE 
ALIASES: 

TTPE:  DATA  ELEMENT  I  DATA  FLOV  I  FILE 

DESCRIPTION:  This  la  a  aaaaaga  coda  in  taxt  that  caa  ba  naad  to  fnrthar 
identify  tha  aaaaaga  or  warning  or  orror. 


COMPOSITION: 

ORGANIZATION  (If  f llo) : 

NOTES:  Thia  caa  ba  aaad  aa  aa  ladax  by  a  program  or  aa  a  rafaraaca  to  find 
a  aora  datallad  axplaaation  of  aa  arror  or  aaaaaga. 


NAME:  MSG.TEIT 
ALIASES: 

TTPE:  DATA  ELEMENT  I  DATA  FLOV  |  FILE 

DESCRIPTION:  Thia  ia  a  ataadard  format  taxt  string  with  hnnaa-raadabla  aosaago. 
COMPOSITION: 

ORGANIZATION  (If  f ila) : 

NOTES: 


NAME:  NEXT-TIME 
ALIASES: 

TTPE:  DATA  ELEMENT  I  DATA  FLOV  |  FILE 

DESCRIPTION:  Thia  ia  tha  naxt  tin*  at  which  aoao  apacifiad  function  ia  to 
ba  dona. 

COMPOSITION: 

ORGANIZATION  (if  f ila) : 

NOTES: 
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NAME:  KEY  .SOURCE 
ALIASES: 

TTPE:  DATA  ELEMENT  I  DATA  FLOW  |  FILE 

DESCRIPTION:  Thla  la  a  logical  variabla  denoting  praatnea  of  aav  latarfaranca 
aonrcaa  that  can  affact  a  communication. 

COMPOSITION:  TRUE  |  FALSE 

ORGANIZATION:  (if  flit): 

NOTES: 


NAME:  OBJECT-TYPE 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOV  I  FILE 

DESCRIPTION:  Part  of  EVENT-DATA,  thla  parameter  danotaa  which  typa  of  object 
ia  to  ba  ganaratad  by  GENERATE-OBJECT. 

COMPOSITION: 

ORGANIZATION  (If  f ila) : 

NOTES: 


NAME:  ORDER  OF -BATTLE 
ALIASES: 

TTPE:  DATA  ELEMENT  I  DATA  T  LOW  I  FILE 

DESCRIPTION;  Thia  ia  tha  initial  ordar  of  battla  including  equipment  and  fercaa. 
COMPOSITION: 

ORGANIZATION  (if  flla): 


NAME:  ORIENTATION 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW \  FILE 
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DESCRIPTIOI:  The  orientation  of  an  objoct  deformed  by,  for  example,  Enlor  angle. 
COMPOSITIOI: 

ORGANIZATION  (if  f ilo) : 

VOTES: 


FAME:  OUTPUT-LOO 

ALIASES: 

TYPE:  DATA  ELEMEHT  I  DATA  FLOW  I  FILE 

DESCRIPTIOI:  Thio  lo  a  text  filo  containing  periodic  coda  aad  alnnlatloa 

information  aad  all  orror  aad  warning  aoaaagoa.  Thla  will  havo 
all  aaar  coaaaada  aad  massages  that  appear  oa  tha  DISPLAYS  data 
doflaitioaa.  All  orrora,  warnings,  aad  actloaa  takaa  will  ba 
included  la  a  tlaa-ordarad  Banner.  Alao  Included  la  thla 
daacriptioa  night  ba  a  aat  of  flleo  -  oaa  for  each  aide  la  a 
battle  ainulatioa  aad  oaa  for  tha  overall  alnnlatloa  run. 

COMPOSITIOI:  {ERROR -MSG}  ♦  {WARS INC _MSG}  ♦  {DISPLAYS} 

ORGANIZATION  (if  file): 

NOTES:  All  procaaaaa  write  into  thla  file  aa  required.  It  la  ganaral  ia  not 
ahova  oa  tha  data  flow  dlagraaa  because  it  nahaa  than  too  conplicatad. 


NAME:  PACKET  (generic) 

ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW I  FILE 

DESCRIPTION:  Thia  ia  tha  generic  forn  of  the  aoaaagoa  that  are  transmitted 

fron  asset  to  aaaat. 

COMPOSITION:  IHFO-PTR  ♦  ZMIT.ID  ♦  RCVR  ID  ♦  INFO-DATA 
ORGANIZATION  (if  file) : 

NOTES:  Thera  will  ba  many  different  f ornate  of  tha  data  flolda  for  the 

varloua  aaaata. 

IMIT.ID  aad  RCVR-ID  are  tha  SV.ID’a  for  tha  trananitter  aad  receiver, 
respectively.  Sea  SVID  for  noro  information. 


DATA  DEFINITIONS 


8-26 


DATA  DEFINITIONS 


NAME:  PATH -FUNCTIONS 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOV  |  FILE 

DESCRIPTION:  Path  function*  ax*  tins-  and  fraqusncy-dapsndsnt  functions  that 
daacrlba  ths  transformations  of  TRANSMITTED  .PACKET (a)  Into 
INCIDENT -PACKET  (b)  . 


COMPOSITION: 
ORGANIZATION  (If  f 11a) : 
NOTES: 


NAME:  PERCEIVED -ATTRIBUTES 
ALIASES: 

TYPE:  DATA  ELQ4ENT  |  DATA  FLOW I  FILE 

DESCRIPTION:  Thsss  ars  paraastsrs  ‘ 'measured"  by  a  ssnsor  for  oach  objsct 
dstsctad . 

COMPOSITION: 

ORGANIZATION  (if  fils): 

NOTES: 


NAME:  PERCEIVED.  OBJECT -ATTRIBUTES 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW  I  FILE 

DESCRIPTION:  This  is  ths  local  fils  containing  th*  results  of  a  SENSOR'S 
observations.  Ths  infornatlon  containsd  in  it  is  proessssd 
to  construct  an  INFO -PACKET. 


COMPOSITION: 
ORGANIZATION  (if  fils): 
NOTES: 
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HiME:  PERCEIVED -WORLDS 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW  [  FILE 

DESCRIPTION:  Thlk  it  tba  perception  of  tba  world  as  sssn  by  tbs  combatants 
and  tbs  asssts  belonging  to  tbs  combatant*. 

COMPOSITION:  BATTLE-ORDER  + 

t com bat ants  tasssts 
{  {  (  {  STATE-VECTOR}  ) 

♦  (  {  RECORDED. OBSERVATION}  ) 

♦  (  {  RECORDED  .DECISION}  ) 

+  (  {  ATTACK.PLAH  }  ) 

♦  (  {  PLANNED  -RESPONSE  }  ) 

♦  c  {  BATTLE-MCR-DIRECTIVE  }  )  }  } 

♦  ENVIRONMENT 

ORGANIZATION  (if  file):  The  boundaries  In  this  fils  are  absolute.  For 
example,  no  asset  can  look  directly  at  another  asset's 
PERCE  I VED  WORLDS .  Spies  are  an  exception  to  this. 


NOTES: 


NAME:  P&TSICAL-OUTPtJT 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW  I  FILE 

DESCRIPTION:  This  is  the  hardcopy  (•.(.,  film,  paper,  etc.)  ontpnt  available 
to  the  user. 

COMPOSITION:  DISPLAYS 

ORGANIZATION  (if  file): 

NOTES: 


NAME:  PLANNED JIESPONSB 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW  |  FILE 

DESCRIPTION:  This  ie  the  pre-planned  response  of  a  combattant  to  an  attack. 
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COMPOSITION: 
ORGANIZATION  (If  fils) : 
NOTES: 


BAKE:  POSITION 
ALIASES: 

TYPE:  DATA  ELEMENT!  DATA  FLOW  |  FILE 
DESCRIPTION:  This  la  tha  location  of  an  objact. 

COMPOSITION: 

ORGANIZATION  (if  f ila) : 

NOTES:  It  may  ba  naeaaaary  to  carry  position  in  anltlpla  coordinate  systama 
to  allow  aora  affleiant  calculations. 


NAME:  POST-PROCESSING 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLO*  |  FILE 

DESCRIPTION:  Thass  ara  tha  raw  data  collsctad  daring  a  aianlation  run  that 
nay  ba  raducad  and  analysad  following  tha  run. 


COMPOSITION: 

{REAL.VORLD}  ♦  { PERCE  I VED  -WORLDS }  *  {SCENARIO} 
♦  {EVENT-q}  4  {CODE-DATA}  ♦  {SIM-DAIA} 

+  {INFO -PACKETS} 

ORGANIZATION  (if  fils): 


NAME:  P REV. TIME 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOI  |  FILE 

DESCRIPTION:  This  ia  tha  tlaa  at  which  tha  previous  aianlation  calculation 
or  activity  took  place  for  an  event. 


COMPOSITION: 
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ORGANIZATION  (if  f lit) : 
MOTES: 


SAME:  REAL  WORLD 
ALIASES: 

TTPE:  DATA  ELEMENT  I  DATA  FLOW  |  FILE 

DESCRIPTION  This  it  tht  world  at  it  actually  and  prtcitaly  axiata.  Thara 
art  no  arrora  in  tha  raal  world. 

COMPOSITION: 

{STATE  VECTOR}  /*  for  all  aaaata  */ 

4  ENVIRONMENT  ♦  CONSTANTS  /*  a.*.,  pi.  apaad  of  light,  ate.  */ 
«  CEOCRAPHT 
ORGANIZATION  (if  f ila) : 

NOTES: 


NAME:  RECEIVED -PACKET 
ALIASES: 

TTPE:  DATA  ELEMENT  |  DATA  FLOW I  FILE 

DESCRIPTION:  Thia  ia  a  coaannication  packat  that  ia  dalivarad  by  tha  racaivar. 
It  ia  tha  INCIDENT-PACKET  aodlfiad  by  tha  racaivar  tranafar 
function.  For  a  porfact  racaivar,  it  ia  ldantical  to  tha 
INCIDENT .PACKET. 

COMPOSITION:  PACKET 

ORGANIZATION  (if  f ila) : 

NOTES: 


NAME:  RECEIVER-ID 
ALIASES: 

TTPE:  DATA  ELEMENT  I  DATA  FLOW  |  FILE 

DESCRIPTION:  Thia  data  alaaant  idantiflaa  tha  particular  coaaunlcatlona 
racaivar  to  which  a  packat  ia  aant. 


DATA  DEFINITIONS 


8-30 


DATA  DEFINITIONS 


COMPOSITION: 
ORGANIZATION  (If  fila): 
NOTES:  Ihio  la  a  SV.ID 


NAME:  RECORDED  DECISION 
ALIASES: 

TTPE:  DATA  ELEMENT  |  DATA  FLOI  |  FILE 

DESCRIPTION:  Ihia  ia  a  recorded  daclaloo  aada  by  ao&e  particular  battla 
■an agar . 

COMPOSITION: 

ORGANIZATION  (If  file): 

NOTES: 


NAME:  RECORDED  .OBSERVATION 
ALIASES: 

TTPE:  DATA  ELEMENT  I  DATA  FLOV  I  FILE 

DESCRIPTION:  Thia  la  a  racordad  perception  of  bobo  particular  eanaor. 
COMPOSITION: 

ORGANIZATION  (If  flla): 

NOTES: 


NAME:  REF-LIBRART 
ALIASES: 

TTPE:  DATA  ELEMENT  |  DATA  FLOV  |  FILE 

DESCRIPTION:  Thaaa  ara  tha  varlona  varaiosa  of  the  DETEC  data  baaa  aa 

maintain ad  by  tha  SOURCE  CODE  CONTROL  8TSTEM.  Tba  data  baaa 
conalatB  of  phyaical  conatante,  geography ,  aaaat  daacriptlona,  ate.. 


COMPOSITION: 
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ORGANIZATION  (If  file): 
NOTES: 


NAME:  RESTART -DUMPS 
ALIASES: 

ITPE:  DATA  ELEMENT  I  DATA  FLOW  I  FILE 

DESCRIPTION:  This  la  •  fila  containing  all  data  naeaaaary  to  raanna  a 
■ianlatlon  ran  aa  If  it  Rad  not  baon  interrupted. 


COMPOSITION: 

{  {SCENARIO}  ♦  {REAL-VORLD}  ♦  (PERCEIVED .WORLDS} 
♦  {EVENT. 0}  ♦  {INFO  PACKETS}  ♦  {CODE-DATA} 

+  {IN  PROGRESS}  ♦  {PATH -FUNCTIONS}  } 

ORGANIZATION  (if  fila): 


NOTES: 


NAME:  SAVE-SV 
ALIASES: 

TTPE:  DATA  ELEMENT  I  DATA  FLOW  |  FILE 

DESCRIPTION:  Thia  ia  a  flag  which  indicate*  whathar  a  atata  vactor  an at  ba 
savad  if  changed. 

COMPOSITION:  TRUE  I  FALSE 

TRUE  -  aava  atata  vector 
FALSE  -  do  not  aava  atata  vactor 

ORGANIZATION  (if  fila) : 

NOTES: 


NAME:  SCENARIO 
ALIASES: 

TTPE:  DATA  ELEMENT  |  DATA  FLOW  |  FILE 
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DESCRIPTION :  This  la  tha  pradaflaad  serial  of  actions ,  svonto,  and 
constraints  that  drlvs  and  control  ths  simulation. 

COMPOSITION: 

•combatants 

{  (ATTACK -PLAN)  ♦  (PLANNED  RESPONSE)  } 

♦  ( INTERVENTIONS)  /*  Events  and  change*  which  ara  nsad  to 
trigger  natural  and  omnipotent  actions  •/ 

♦  (ORDER  . OF  BATTLE) 

ORGANIZATION  (if  file): 

NOTES:  This  defines  Intent,  of  the  plane,  combatant  assets  and  status,  times 
of  launch,  and  battle-manager  instructions  and  constraints. 
Interventions  are  sometimes  referred  to  as  acts  of  God. 


FAME:  SCENARIO -LIBRART 
ALIASES: 

TTPE:  DATA  ELEMENT  |  DATA  FLOW  I  FILE 

DESCRIPTION:  These  are  the  various  ecenarioe  that  are  saved  and  maintained 
by  the  SOURCE  CODE  CONTROL  STSTQ4. 

COMPOSITION: 

ORGANIZATION  (if  file) : 

NOTES: 


NAME:  SENSOR. OPERATING -PARAMETERS 
ALIASES: 

TTPE:  DATA  ELEMENT  |  DATA  FLOW I  FILE 

DESCRIPTION:  This  is  information  describing  parameters  such  as  threshold  and 
frequency  range  to  be  used  for  the  SENSOR  operations. 

It  is  extracted  from  EVENT -DATA. 


COMPOSITION: 
ORGANIZATION  (if  file): 
NOTES: 
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NAME:  SIM -DATA 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW  I  FILE 

DESCRIPTION:  This  Information  gives  tho  ntnto  or  ntntnn  of  tho  simulated 
battle (n) . 

COMPOSITION:  Thin  is  tho  binary  sschlno  ropros notation  of  data  tbs  nsar  had 
requested  for  processing  Into  tho  POST -PROCESSING  and 
RESTART-DUMPS  film. 

ORGANIZATION  (if  file) : 

NOTES:  Thin  is  vary  closoly  rolatod  to  SIMJiTATUS  in  that  ths  us  or  has 
roqnostsd  to  log  simulation  data  hors  in  a  machins  form  whore 
SIM-STATUS  is  la  a  text  nssr-rsadablo  form. 


NAME:  SIM-STATUS 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW I  FILE 

DESCRIPTION:  This  is  tho  status  of  tho  simulated  battlo(s)  as  displayed  for 
tho  nsor. 

COMPOSITION :  This  is  text  representation  of  simulation  data  that  the  user  has 
requested  to  vie*  either  in  DISPLAYS  and/or  OUTPUT-LOG 

ORGANIZATION  (if  file): 

NDIES:  See  SINJ)ATA  for  clarification  of  tho  differences  between  SIM-STATUS 
and  SINJ>ATA. 


NAME:  SOURCE 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW  |  FILE 

DESCRIPTION:  This  identifies  the  module  that  originated  tho  message,  data, 
or  function. 

COMPOSITION: 

ORGANIZATION  (if  file): 
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NOTES: 


JUNE:  STATE -VECTOR  (generic) 

ALIASES: 

ITPE:  DATA  ELEMENT  I  DATA  FLOW  I  FILE 

DESCRIPTION:  This  ia  the  standard  def Initios  of  an  object ’a  position, 
velocity,  atatna,  and  all  othsr  existing  paraaatara. 

COMPOSITION: 

SV  ID  «  POSITION  4  ORIENTATION  «  SV.CLASS.ID 
4  DAMAGE  4  SV _  4  SAVE  -SV 

ORGANIZATION  (If  f 11a) : 

NOTES: 


NAME:  SV -CLASS-ID 

ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW  |  FILE 

DESCRIPTION:  This  ia  an  alphanonerlc  idantlflar  for  aach  class  of 

STATE-VECTORS.  A  class  nay  ba  daf  load  as  all  STATE-VECTORa 
that  follow  tha  aana  algorithm  for  normal  (nndistnrbad) 
tins  svolntion  bnt  nay  hava  different  values  for  paranatar 
naad  in  tha  algor lthn.  Thaaa  parameters  are  part  of  aach 
STATE -VECTOR. 

COMPOSITION: 

ORGANIZATION  (If  file); 

NOTES: 


NAME:  SV.ID 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW  |  FILE 

DESCRIPTION:  This  la  a  unique  identification  for  a  state  vector. 
COMPOSITION: 
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ORGANIZATION  (if  f ill) : 
NOTES: 


NAME:  SYSTEM-TABLES 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW  I  FILE 

DESCRIPTION:  This  is  a  fils  accssssd  to  changs  or  rstrisvs  ths  status  of  tha 
DETEC  cods  vithin  ths  CTSS  systsa.  This  vill  bs  iaplsasatsd  by 
library  calls  to  ths  appropiats  systsa  function. 

COMPOSITION:  Systsa  paraastsrs  (to  bs  dsfinsd  as  rsquirsd) 

ORGANIZATION  (if  fils) : 

NOTES: 


NAME:  TEXT-MSG 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW  I  FILE 

DESCRIPTION:  This  is  ths  standard  foraat  taxt  asssags  dssignsd  for  human 
undsstanding. 

COMPOSITION:  DATE-TIME  ♦  MODULE-NAME  ♦  MSG -CODE  ♦  MSG -TEXT 
ORGANIZATION  (if  fils) : 

NOTES: 


NAME:  TIME 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW  |  FILE 

DESCRIPTION:  This  is  ths  binary  tias  as  aalntalnsd  by  ths  slaulation  program. 
COMPOSITION: 

ORGANIZATION  (if  fils): 

NOTES: 
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NAME:  mss  CHARACTERISTICS 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW I  FILE 

DESCRIPTION:  This  data  flow  doacrlbea  th«  char act aria tics  of  a  communications 
transmitter,  inch  aa  frequency  band,  povar  distribution  fanctioa, 
power  lavaX,  ate. 


COMPOSITION: 
ORGANIZATION  (If  f 11a) ; 
NOTES: 


NAME:  TRANSMITTED -PACKET 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW I  FILE 

DESCRIPTION:  Thia  la  the  communications  packet  that  was  actually  transmitted. 

It  la  the  INTENDED  .PACKET  modified  by  tranaaittar  tranaf ar  function. 
For  a  perfect  tranaaltter.  It  la  identical  to  the  INTENDED-PACKET. 

COMPOSITION:  PACKET 

ORGANIZATION  (if  file) : 

NOTES: 


NAME:  TRANSMITTER. ID 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW  |  FILE 

DESCRIPTION:  Thlt  data  element  identifies  tha  particular  common 1 eat Iona 
tranaaittar  that  sends  a  packet. 

COMPOSITION: 

ORGANIZATION  (if  fils) : 

NOTES:  This  la  a  SV.ID 
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NAME:  VIEWABLE.OB  JEC  T-LI  ST 
ALIASES: 

TYPE:  DATA  ELEMENT  |  DATA  FLOW  I  FILE 

DESCRIPTION:  This  ia  a  fila  containing  IDs  of  tho  STATE-VECTOR  of  *11 
objacta  datarminad  to  bo  viawabla  by  tbo  Filtar. 

COMPOSITION:  {SV.ID} 

ORGANIZATION  (if  flla) : 

NOTES: 


NAME:  WARNING -MSG 
ALIASES: 

TYPE:  DATA  ELEMENT  I  DATA  FLOW I  FILE 

DESCRIPTION:  Tbla  la  an  information  aaaaaga  daacrlblng  a  poaalbly  abnormal 
condition. 

COMPOSITION:  TEXT -MSG 
ORGANIZATION  (if  flla): 

BOTES: 
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APPENDIX  A.  STRUCTURED  ANALYSIS  CONVENTIONS 


Reference:  Structured  Analysis  and  System  Specification 
by  Tom  De  Marco 

Data  Ftew  Notation: 


Data  source 
or  sink 


Dataflow 


data  transform  or  process  -  Input  data 
are  transformed  Into  output  data 


a  file  -  data  storage 


Data  now  Example: 


The  test  data  for  the 
specified  test  nunber 
are  taken  from  the  file 
and  transformed  Ho 
results. 
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Data  Dictionary  Notation: 

=  means  "is  equivalent  to" 

♦  means  "and" 

means  "either-or"  i.e.,  select  one  of  the 
options 

)  |  means  "iterations  of  the  component 
enclosed 

( )  means  the  enclosed  component  is 


"optional" 

|  means  "or" 

Data  Dictionary  Examples: 

COMMAND  =  [START  |  STOP  |  ABORT] 

-  select  one  of  the  options 
DATA-BASE  =  1SH0T-DATA  +  SHOT-NUMBER  + 


(SUBSYSTEM -ID)| 

—the  data  base  consists  of  multiple  sets 
of  shot  data  and  shot  number  and 
an  optional  subsystem  identification. 
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NAMING  CONVENTIONS 


BM  -  battle-manager  process 
CM  -  communications  process 
CMD  -  command 
EG  -  engagement 
ENV  -  environment 
EP  -  event  physics  process 
EQ  -  event  queue  file 
EV  -  event 

EX  -  executive  process 
IN  -  in  progress  file 
INTEL  -  intelligence 
IP  -  information  packet 
LG  -  logger  process 
MN  -  mother  nature  process 
MR  -  manager  process 
PF  -  path  functions  file 
PP  -  postprocessing  file 
PTR  -  pointer 
PW  -  perceived  world  file 
Q  -  queue 

RD  -  restart  dumps  file 
RW  -  real-world  file 
SC  -  scenario  file 
SN  -  sensor  process 
SV  -  state  vector 
WP  -  weapons  process 
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This  is  an  alternative  proposal  for  the  Executive  conflict  handler. 


1  . 

2  CO UEH  -  CONFLICT  HANDLES 

3  . 

A  DEFINITIONS  - 

5  II  -  Initial  tlaa  for  C0NH4I  ••arch 

6  TH  ■  Tima  horizon  for  C0NH1I  anarch 

7  TB  *  Begin  tlmn  for  extended  nvonfe 

8  TE  *  End  tlmn  for  extended  event 

9  TET  ■  Temporary  end  tlmn  for  extended  avant 

10  TC  *  Check  time 

11  TCP  ■  Previous  check  time 

12  TH  ■  First  mismatch  tlaa  in  EVENT  Q  comparison 

15  CBN  •  Check  avant 

14  SCH  *  Search  event 

16  ITP  *  Interval  type  flag 

10  Interval  types  are: 

17  AF  ■  Asset  Fnnction  (ITP-AF) 

18  EP  ■  Event  Physics  (ITP*ff) 

19  LBL  *  Interval  label 

20  Ai  *  Set  of  labels  for  EP  Intervals  that  evarlap  AF 

21  intarvals,  for  sssst  1. 

22  Bi  *  Set  of  labole  for  rotponelve  EP  Intervals, 

23  for  assst  1, 

24  Bsaponalvsnsas  of  an  EP  lntarval  implies  that  EP  acting 
26  npon  asset  i  hen  the  potential  of  croating  new  events 

26  within  the  EP  Interval. 

27 

28  FUNCTION  -  Thin  module  searches  tha  lntarval  [II, TH]  is  the 

29  EVENT.!)  for  conflict  events  and  antabllahee  conflict 

30  proctas  control  by  setting  state  vector  flags  and  spawning 

31  now  svents.  This  is  accomplished  by  melmg  eat  theory. 

32  . . . 

33  CONEAN  (EVENT _PTR) 

34  /*  Compare  EVENT  J)  with  EVENT  J).DLD  over  [ICP.IC]  •/ 

36  IF  (CHK  AND  E VEST-1)  «  EVENT -I) -OLD)  ,  THEN 

38  TCP  -  TC 

37  ELSE 

38  IF  (SCH) ,  THEN 

39  II  ■  TH 

40  TCP  -  II 

41  CALCULATE  NEXT  TIME  HORIZON  (TH) 

42  INSERT  SCH  IN  EVENT -Q 

43  INSERT  CHK (S)  IN  EVENT.!) 

44  ELSE 

46  FIND  TH 
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46 

47 

48 

4ft 

50 

El 

Eft 

E3 

E4 

EE 

E6 

E7 

E6 

Eft 

60 

61 

63 

63 

64 

66 

66 

67 
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TI  ■  TM 
END  IF 

WRITE  EVENT  q  F01  [TI.TH]  II  EVENT  _q_OLD 

SEARCH  [TI.TH]  FOR  EVENTS  THAT  HAVE  ASSETS  If  CONNOR 

/*  Ecu  to  horlaon  */ 

DO  FOR  EACH  ASSET  (1) 

TET  -  TE 
IF  (TH  <  TE),  THEN 
TET  -  TH 
END  IF 

COMPOTE  TIME  INTERVAL  [IB, TET] 

ASSIGN  INTERVAL  TYPE  AID  LABEL  (ITP.LBL) 

CHECK  FOR  OVERLAP  OF  TIME  INTERVALS  AND  LOAD  A1 
CHECK  COUPLING  MATRIX  F01  RESPONSIVENESS  AND  LOAD  B1 
IF  (A1  OR  Bi) .  THEN 

FURTHER  INTERVAL  TESTS  /•  May  not  bo  noeoaoaryl  */ 
SET  CONFLICT  FLAGS  IN  EVENT-DATA  (IIP) 

END  IF 
END  DO 
END  IF 
RETURN 


APPENDIX  C 


Printed  In  the  United  Since*  of  America 
Available  from 

National  Technical  In  forma  lion  Service 
US  Department  of  Commerce 
5285  Port  Royal  Road 
Springfield,  VA  22161 

Microfiche  (AOl) 


Page  Range 

NTIS 

Price  Code 

Page  Range 

NTIS 

Price  Code 

001  025 

A02 

15  MTS 

AOS 

026  050 

A03 

176  200 

A  00 

03  107  5 

AOt 

201  223 

A 10 

076  100 

A05 

226  250 

All 

101-125 

A  06 

231  275 

AI2 

126  150 

A07 

276  300 

AJ3 

Page  Range 

NTIS 

Price  Code 

Page  Range 

NTIS 

Price  Code 

301  325 

A 14 

451475 

A  20 

326  350 

A 13 

476  500 

A2I 

351  375 

A  16 

SOI  525 

A22 

376  400 

A 17 

326-550 

A23 

401-425 

A  IS 

351-575 

A  24 

426430 

A 19 

576  600 

A25 

601  up* 

A99 

'Com  act  NTIS  for  a  price  quote. 


